template: preserve quoted numeric strings in DeepCopyWithTemplate - #5098
Conversation
Signed-off-by: Holger Waschke <holger.waschke@dvag.com>
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthrough
ChangesTemplate processing
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
template/template_test.go (1)
696-703: Add one nested payload regression case for end-to-end parity.Current case validates scalar behavior well, but a nested object case (Jira-style field map) would better lock the original regression path.
🧪 Suggested test case extension
@@ { title: "quoted numeric string stays string", input: "hello", fn: TemplateFunc(func(string) (string, error) { return "\"123\"", nil }), want: "123", }, + { + title: "quoted numeric string stays string in nested map", + input: map[string]any{ + "customfield_11209": map[string]any{ + "id": "TOKEN", + }, + }, + fn: TemplateFunc(func(s string) (string, error) { + if s == "TOKEN" { + return "\"15129\"", nil + } + return s, nil + }), + want: map[string]any{ + "customfield_11209": map[string]any{ + "id": "15129", + }, + }, + },🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@template/template_test.go` around lines 696 - 703, Add a new table test case to cover the nested-object regression: create a test row (e.g., title "quoted numeric string in nested payload stays string") alongside the existing case in template_test.go that uses TemplateFunc to return a nested payload like a Jira-style fields map where the value is a quoted numeric string (for example a map {"fields": {"customfield_12345": "\"123\""}}), and assert the processed output preserves the string value "123" (not numeric). Reference the existing test harness and TemplateFunc usage so the new case mirrors the scalar case but with the nested object shape to lock the regression.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@template/template_test.go`:
- Around line 696-703: Add a new table test case to cover the nested-object
regression: create a test row (e.g., title "quoted numeric string in nested
payload stays string") alongside the existing case in template_test.go that uses
TemplateFunc to return a nested payload like a Jira-style fields map where the
value is a quoted numeric string (for example a map {"fields":
{"customfield_12345": "\"123\""}}), and assert the processed output preserves
the string value "123" (not numeric). Reference the existing test harness and
TemplateFunc usage so the new case mirrors the scalar case but with the nested
object shape to lock the regression.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 14633b63-013a-4316-bf02-0988e8a40f0a
📒 Files selected for processing (2)
template/template.gotemplate/template_test.go
|
Thank you @holger-waschke. LGTM |
|
Loosely related to #5012 |
…htemplate Signed-off-by: Holger Waschke <waschkester@gmail.com>
Looks reasonable to me, I added the unit test to the template_test.go |
themavik
left a comment
There was a problem hiding this comment.
Using a string type assert after yaml.Unmarshal fixes quoted numeric template output regressing to float recursion in DeepCopyWithTemplate. nit: TrimSpace-only early return means quoted strings with only whitespace still recurse—odd but probably harmless.
5669b3d to
c9b1d81
Compare
|
Updated branch with main, resolving merge conflicts from #5304. Ready to be merged. |
There was a problem hiding this comment.
I think this PR fixes a narrow issue, but we need more test cases here since this affects 3 integration: Jira, PagerDuty and Webhook:
- a Jira test which uses
toJsonon a numeric string and expects and output like{"id":"1234"}in the body - regression test for ordinary string like
issue # 1234 - test for existing numeric values being rendered as integers
- test for a JSON object with numeric strings stays as is
Co-authored-by: Siavash Safi <git@hosted.run> Signed-off-by: Holger Waschke <85643002+holger-waschke@users.noreply.github.com>
Add Jira coverage for numeric strings rendered with toJson and verify that plain strings, numeric values, and JSON numeric strings retain their intended types. Signed-off-by: Holger Waschke <holger.waschke@dvag.com>
9b163c3 to
e06c572
Compare
|
@holger-waschke There is a ci failure now. |
Signed-off-by: Holger Waschke <holger.waschke@dvag.com>
7229e5c to
e9febdf
Compare
Whoopsie, all green now. |
This fixes an issue where a quoted numeric string produced by DeepCopyWithTemplate could end up being serialized as an integer instead of a string.
One concrete case is Jira custom fields that expect a payload like:
{"id":"15129"}
Before this change, the rendered field could become:
{"customfield_11209":{"id":15129}}
In that form, id was sent as an integer, which Jira rejected.
With this change, quoted numeric values are preserved as strings, so the generated payload keeps the expected type.
A regression test was added to cover this case.