-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🐛 bug: Fix square bracket notation in Multipart FormData #3235
base: main
Are you sure you want to change the base?
Conversation
WalkthroughThe changes in this pull request enhance the multipart form data handling in the Changes
Assessment against linked issues
Possibly related PRs
Suggested reviewers
Tip CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3235 +/- ##
==========================================
- Coverage 84.40% 84.10% -0.31%
==========================================
Files 116 116
Lines 11485 11516 +31
==========================================
- Hits 9694 9685 -9
- Misses 1374 1401 +27
- Partials 417 430 +13
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 5
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
bind_test.go
(4 hunks)binder/form.go
(1 hunks)
🧰 Additional context used
🪛 GitHub Check: codecov/patch
binder/form.go
[warning] 60-67: binder/form.go#L60-L67
Added lines #L60 - L67 were not covered by tests
[warning] 70-77: binder/form.go#L70-L77
Added lines #L70 - L77 were not covered by tests
🪛 golangci-lint (1.62.2)
bind_test.go
998-998: Error return value of writer.WriteField
is not checked
(errcheck)
999-999: Error return value of writer.WriteField
is not checked
(errcheck)
1000-1000: Error return value of writer.Close
is not checked
(errcheck)
1019-1019: Error return value of writer.WriteField
is not checked
(errcheck)
1020-1020: Error return value of writer.WriteField
is not checked
(errcheck)
1021-1021: Error return value of writer.Close
is not checked
(errcheck)
[warning] 1238-1238: unhandled-error: Unhandled error in call to function mime/multipart.Writer.WriteField
(revive)
1238-1238: Error return value of writer.WriteField
is not checked
(errcheck)
[warning] 1240-1240: unhandled-error: Unhandled error in call to function mime/multipart.Writer.Close
(revive)
1240-1240: Error return value of writer.Close
is not checked
(errcheck)
[warning] 1278-1278: unhandled-error: Unhandled error in call to function mime/multipart.Writer.WriteField
(revive)
1278-1278: Error return value of writer.WriteField
is not checked
(errcheck)
[warning] 1279-1279: unhandled-error: Unhandled error in call to function mime/multipart.Writer.WriteField
(revive)
1279-1279: Error return value of writer.WriteField
is not checked
(errcheck)
[warning] 1280-1280: unhandled-error: Unhandled error in call to function mime/multipart.Writer.WriteField
(revive)
[warning] 1281-1281: unhandled-error: Unhandled error in call to function mime/multipart.Writer.WriteField
(revive)
[warning] 1282-1282: unhandled-error: Unhandled error in call to function mime/multipart.Writer.WriteField
(revive)
[warning] 1284-1284: unhandled-error: Unhandled error in call to function mime/multipart.Writer.Close
(revive)
🪛 GitHub Check: lint
bind_test.go
[failure] 998-998:
Error return value of writer.WriteField
is not checked (errcheck)
[failure] 999-999:
Error return value of writer.WriteField
is not checked (errcheck)
[failure] 1000-1000:
Error return value of writer.Close
is not checked (errcheck)
[failure] 1019-1019:
Error return value of writer.WriteField
is not checked (errcheck)
[failure] 1020-1020:
Error return value of writer.WriteField
is not checked (errcheck)
[failure] 1021-1021:
Error return value of writer.Close
is not checked (errcheck)
[failure] 1238-1238:
unhandled-error: Unhandled error in call to function mime/multipart.Writer.WriteField (revive)
[failure] 1238-1238:
Error return value of writer.WriteField
is not checked (errcheck)
[failure] 1240-1240:
unhandled-error: Unhandled error in call to function mime/multipart.Writer.Close (revive)
[failure] 1240-1240:
Error return value of writer.Close
is not checked (errcheck)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (2)
bind_test.go (2)
992-1032
: LGTM! Consider adding edge cases.The new test cases effectively validate both dot notation and square bracket syntax for multipart form data binding. The tests are well-structured and consistent with the existing test patterns.
Consider adding test cases for:
- Empty arrays
- Invalid indices
- Mixed notation (e.g.,
data[0].name
anddata.1[name]
)- Special characters in field names
Line range hint
992-1302
: Overall implementation looks solidThe implementation successfully adds support for square bracket notation in multipart binding while maintaining compatibility with dot notation. The test coverage is good, though it could be expanded to cover more edge cases. The benchmarks provide performance validation but need the variable fixes mentioned above.
Since this feature provides two different notations for the same functionality, consider:
- Documenting the preferred notation in comments
- Adding examples in the test file showing when to use each notation
- Ensuring consistent performance between both notations through benchmarks
🧰 Tools
🪛 GitHub Check: unit (1.23.x, macos-13)
[failure] 1238-1238:
undefined: t
[failure] 1239-1239:
undefined: t
[failure] 1277-1277:
undefined: t
[failure] 1278-1278:
undefined: t
[failure] 1279-1279:
undefined: t
[failure] 1280-1280:
undefined: t
[failure] 1281-1281:
undefined: t
[failure] 1282-1282:
undefined: t
[failure] 1238-1238:
undefined: t
[failure] 1239-1239:
undefined: t🪛 GitHub Check: unit (1.23.x, macos-latest)
[failure] 1238-1238:
undefined: t
[failure] 1239-1239:
undefined: t
[failure] 1277-1277:
undefined: t
[failure] 1278-1278:
undefined: t
[failure] 1279-1279:
undefined: t
[failure] 1280-1280:
undefined: t
[failure] 1281-1281:
undefined: t
[failure] 1282-1282:
undefined: t🪛 GitHub Check: unit (1.23.x, ubuntu-latest)
[failure] 1238-1238:
undefined: t
[failure] 1239-1239:
undefined: t
[failure] 1277-1277:
undefined: t
[failure] 1278-1278:
undefined: t
[failure] 1279-1279:
undefined: t
[failure] 1280-1280:
undefined: t
[failure] 1281-1281:
undefined: t
[failure] 1282-1282:
undefined: t
[failure] 1238-1238:
undefined: t
[failure] 1239-1239:
undefined: t🪛 GitHub Check: lint
[failure] 1238-1238:
undefined: t
[failure] 1239-1239:
undefined: t
[failure] 1277-1277:
undefined: t
[failure] 1278-1278:
undefined: t
[failure] 1279-1279:
undefined: t
[failure] 1280-1280:
undefined: t
[failure] 1281-1281:
undefined: t
[failure] 1282-1282:
undefined: t (typecheck)
[failure] 1238-1238:
undefined: t
[failure] 1239-1239:
undefined: t
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
bind_test.go
(4 hunks)
🧰 Additional context used
🪛 GitHub Check: unit (1.23.x, macos-13)
bind_test.go
[failure] 1238-1238:
undefined: t
[failure] 1239-1239:
undefined: t
[failure] 1277-1277:
undefined: t
[failure] 1278-1278:
undefined: t
[failure] 1279-1279:
undefined: t
[failure] 1280-1280:
undefined: t
[failure] 1281-1281:
undefined: t
[failure] 1282-1282:
undefined: t
[failure] 1238-1238:
undefined: t
[failure] 1239-1239:
undefined: t
🪛 GitHub Check: unit (1.23.x, macos-latest)
bind_test.go
[failure] 1238-1238:
undefined: t
[failure] 1239-1239:
undefined: t
[failure] 1277-1277:
undefined: t
[failure] 1278-1278:
undefined: t
[failure] 1279-1279:
undefined: t
[failure] 1280-1280:
undefined: t
[failure] 1281-1281:
undefined: t
[failure] 1282-1282:
undefined: t
🪛 GitHub Check: unit (1.23.x, ubuntu-latest)
bind_test.go
[failure] 1238-1238:
undefined: t
[failure] 1239-1239:
undefined: t
[failure] 1277-1277:
undefined: t
[failure] 1278-1278:
undefined: t
[failure] 1279-1279:
undefined: t
[failure] 1280-1280:
undefined: t
[failure] 1281-1281:
undefined: t
[failure] 1282-1282:
undefined: t
[failure] 1238-1238:
undefined: t
[failure] 1239-1239:
undefined: t
🪛 GitHub Check: lint
bind_test.go
[failure] 1238-1238:
undefined: t
[failure] 1239-1239:
undefined: t
[failure] 1277-1277:
undefined: t
[failure] 1278-1278:
undefined: t
[failure] 1279-1279:
undefined: t
[failure] 1280-1280:
undefined: t
[failure] 1281-1281:
undefined: t
[failure] 1282-1282:
undefined: t (typecheck)
[failure] 1238-1238:
undefined: t
[failure] 1239-1239:
undefined: t
@efectn Analysis by Key Issues Identified:
Summary of Primary Concerns:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (1)
binder/form.go (1)
71-77
: Consider adding debug logging for complex transformationsWhile the comma-splitting logic is correct, adding debug logging would help troubleshoot issues in production.
for _, v := range values { + // Debug: log.Debug().Str("key", key).Str("value", v).Msg("Processing multipart form value") if strings.Contains(v, ",") && equalFieldType(out, reflect.Slice, key) { temp[key] = strings.Split(v, ",") } else { temp[key] = append(temp[key], v) } }
🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 72-75: binder/form.go#L72-L75
Added lines #L72 - L75 were not covered by tests
[warning] 77-77: binder/form.go#L77
Added line #L77 was not covered by tests
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
bind_test.go
(5 hunks)binder/form.go
(1 hunks)
🧰 Additional context used
🪛 GitHub Check: codecov/patch
binder/form.go
[warning] 66-67: binder/form.go#L66-L67
Added lines #L66 - L67 were not covered by tests
[warning] 72-75: binder/form.go#L72-L75
Added lines #L72 - L75 were not covered by tests
[warning] 77-77: binder/form.go#L77
Added line #L77 was not covered by tests
🔇 Additional comments (7)
binder/form.go (2)
60-80
: LGTM! The implementation addresses key issues.
The changes effectively resolve several issues identified in the PR comments:
- Using a temporary map prevents modification during iteration
- Proper error handling for square bracket notation
- Consistent key usage after transformation
- Improved comma-splitting logic
🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 66-67: binder/form.go#L66-L67
Added lines #L66 - L67 were not covered by tests
[warning] 72-75: binder/form.go#L72-L75
Added lines #L72 - L75 were not covered by tests
[warning] 77-77: binder/form.go#L77
Added line #L77 was not covered by tests
62-69
: Verify error handling in parseParamSquareBrackets
The square bracket parsing looks good, but let's verify the robustness of parseParamSquareBrackets
.
✅ Verification successful
Error handling in parseParamSquareBrackets is robust and well-tested
After reviewing the implementation and tests, the function handles all edge cases appropriately:
- Properly converts bracket notation to dot notation (e.g.,
foo[bar[baz]]
→foo.bar.baz
) - Handles empty inputs and empty brackets (
[]
,""
) - Detects and reports unmatched brackets with clear error message
- Uses bytebufferpool for efficient string building
- Includes proper error handling for write operations
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for parseParamSquareBrackets implementation and its tests
ast-grep --pattern 'func parseParamSquareBrackets($$$) {
$$$
}'
# Search for test cases
rg -A 5 'Test.*parseParamSquareBrackets'
Length of output: 110
Script:
#!/bin/bash
# Let's try a different approach to find the implementation and tests
# First, let's find the file containing the function
rg -l "parseParamSquareBrackets"
# Then let's look at the implementation and surrounding context
rg -B 5 -A 10 "func parseParamSquareBrackets"
# Also search for test files
fd -e go -e _test.go
Length of output: 5855
Script:
#!/bin/bash
# Let's look at the complete implementation and tests
rg -A 20 'func parseParamSquareBrackets' binder/mapping.go
# Get the test cases
rg -A 20 'parseParamSquareBrackets' binder/mapping_test.go
Length of output: 850
Script:
#!/bin/bash
# Let's get more context from the test file to see the test cases
rg -B 10 -A 5 'parseParamSquareBrackets' binder/mapping_test.go
# And let's get the complete implementation as the previous command didn't show the full function
rg -B 2 -A 30 'func parseParamSquareBrackets' binder/mapping.go
Length of output: 1134
Script:
#!/bin/bash
# Let's get the full test cases to see all the scenarios being tested
rg -B 20 -A 5 'result, err := parseParamSquareBrackets' binder/mapping_test.go
Length of output: 537
Script:
#!/bin/bash
# Let's get the complete test cases from the beginning
rg -B 30 'result, err := parseParamSquareBrackets' binder/mapping_test.go
Length of output: 580
🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 66-67: binder/form.go#L66-L67
Added lines #L66 - L67 were not covered by tests
bind_test.go (5)
882-883
: LGTM! Well-structured struct definition.
The Demo struct properly defines tags for all supported binding types.
993-1012
: LGTM! Comprehensive test for dot notation.
The test properly validates multipart form data binding using dot notation.
1014-1033
: LGTM! Good test coverage for square bracket notation.
The test ensures proper handling of square bracket notation in multipart form data.
Line range hint 1270-1297
: Handle errors in nested benchmark setup
Similar to the previous benchmark, proper error handling is needed for writer operations.
buf := &bytes.Buffer{}
writer := multipart.NewWriter(buf)
-require.NoError(b, writer.WriteField("name", "john"))
-require.NoError(b, writer.WriteField("persons.0.name", "john"))
-require.NoError(b, writer.WriteField("persons[0][age]", "10"))
-require.NoError(b, writer.WriteField("persons[1][name]", "doe"))
-require.NoError(b, writer.WriteField("persons.1.age", "20"))
-require.NoError(b, writer.Close())
+if err := writer.WriteField("name", "john"); err != nil {
+ b.Fatal(err)
+}
+if err := writer.WriteField("persons.0.name", "john"); err != nil {
+ b.Fatal(err)
+}
+if err := writer.WriteField("persons[0][age]", "10"); err != nil {
+ b.Fatal(err)
+}
+if err := writer.WriteField("persons[1][name]", "doe"); err != nil {
+ b.Fatal(err)
+}
+if err := writer.WriteField("persons.1.age", "20"); err != nil {
+ b.Fatal(err)
+}
+if err := writer.Close(); err != nil {
+ b.Fatal(err)
+}
1231-1251
:
Handle errors in benchmark setup
The benchmark setup should handle errors from writer operations.
buf := &bytes.Buffer{}
writer := multipart.NewWriter(buf)
-require.NoError(b, writer.WriteField("name", "john"))
-require.NoError(b, writer.Close())
+if err := writer.WriteField("name", "john"); err != nil {
+ b.Fatal(err)
+}
+if err := writer.Close(); err != nil {
+ b.Fatal(err)
+}
Likely invalid or redundant comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
♻️ Duplicate comments (3)
bind_test.go (3)
1001-1020
:⚠️ Potential issueAdd error handling for multipart operations
The test case should handle potential errors from multipart operations.
Apply this diff:
buf := &bytes.Buffer{} writer := multipart.NewWriter(buf) -require.NoError(t, writer.WriteField("data.0.name", "john")) -require.NoError(t, writer.WriteField("data.1.name", "doe")) -require.NoError(t, writer.Close()) +if err := writer.WriteField("data.0.name", "john"); err != nil { + t.Fatal(err) +} +if err := writer.WriteField("data.1.name", "doe"); err != nil { + t.Fatal(err) +} +if err := writer.Close(); err != nil { + t.Fatal(err) +}
1022-1041
:⚠️ Potential issueAdd error handling for square bracket notation test
Similar to the dot notation test, this test case should handle potential errors.
Apply this diff:
buf := &bytes.Buffer{} writer := multipart.NewWriter(buf) -require.NoError(t, writer.WriteField("data[0][name]", "john")) -require.NoError(t, writer.WriteField("data[1][name]", "doe")) -require.NoError(t, writer.Close()) +if err := writer.WriteField("data[0][name]", "john"); err != nil { + t.Fatal(err) +} +if err := writer.WriteField("data[1][name]", "doe"); err != nil { + t.Fatal(err) +} +if err := writer.Close(); err != nil { + t.Fatal(err) +}
1239-1259
:⚠️ Potential issueFix benchmark test variable usage
The benchmark is using
t
instead ofb
for assertions.Apply this diff:
buf := &bytes.Buffer{} writer := multipart.NewWriter(buf) -require.NoError(b, writer.WriteField("name", "john")) -require.NoError(b, writer.Close()) +if err := writer.WriteField("name", "john"); err != nil { + b.Fatal(err) +} +if err := writer.Close(); err != nil { + b.Fatal(err) +}
🧹 Nitpick comments (1)
binder/form.go (1)
80-87
: Consider optimizing value handlingThe nested loop for handling values could be optimized by pre-allocating the slice capacity when splitting comma-separated values.
Apply this optimization:
for _, v := range values { if strings.Contains(v, ",") && equalFieldType(out, reflect.Slice, key) { - temp[key] = strings.Split(v, ",") + parts := strings.Split(v, ",") + temp[key] = make([]string, len(parts)) + copy(temp[key], parts) } else { temp[key] = append(temp[key], v) } }🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 82-82: binder/form.go#L82
Added line #L82 was not covered by tests
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
bind_test.go
(5 hunks)binder/form.go
(1 hunks)
🧰 Additional context used
🪛 GitHub Check: codecov/patch
binder/form.go
[warning] 72-75: binder/form.go#L72-L75
Added lines #L72 - L75 were not covered by tests
[warning] 77-77: binder/form.go#L77
Added line #L77 was not covered by tests
[warning] 82-82: binder/form.go#L82
Added line #L82 was not covered by tests
🔇 Additional comments (4)
binder/form.go (2)
69-78
: LGTM: Safe map iteration with temporary storage
The introduction of a temporary map and proper error handling for square bracket notation parsing is a good approach. This addresses the issue of modifying maps during iteration that was mentioned in the PR comments.
🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 72-75: binder/form.go#L72-L75
Added lines #L72 - L75 were not covered by tests
[warning] 77-77: binder/form.go#L77
Added line #L77 was not covered by tests
89-89
: LGTM: Clean return statement
The final return statement correctly uses the temporary map instead of the original data.Value map.
bind_test.go (2)
890-891
: LGTM: Well-structured struct definition
The Demo struct is properly tagged for multiple serialization formats.
Line range hint 1261-1305
: Fix nested benchmark test variable usage
Similar to the previous benchmark, this test is using incorrect variable for assertions.
Apply this diff:
buf := &bytes.Buffer{}
writer := multipart.NewWriter(buf)
-require.NoError(b, writer.WriteField("name", "john"))
-require.NoError(b, writer.WriteField("persons.0.name", "john"))
-require.NoError(b, writer.WriteField("persons[0][age]", "10"))
-require.NoError(b, writer.WriteField("persons[1][name]", "doe"))
-require.NoError(b, writer.WriteField("persons.1.age", "20"))
-require.NoError(b, writer.Close())
+if err := writer.WriteField("name", "john"); err != nil {
+ b.Fatal(err)
+}
+if err := writer.WriteField("persons.0.name", "john"); err != nil {
+ b.Fatal(err)
+}
+if err := writer.WriteField("persons[0][age]", "10"); err != nil {
+ b.Fatal(err)
+}
+if err := writer.WriteField("persons[1][name]", "doe"); err != nil {
+ b.Fatal(err)
+}
+if err := writer.WriteField("persons.1.age", "20"); err != nil {
+ b.Fatal(err)
+}
+if err := writer.Close(); err != nil {
+ b.Fatal(err)
+}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
⚠️ Performance Alert ⚠️
Possible performance regression was detected for benchmark.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.50
.
Benchmark suite | Current: ddeba87 | Previous: 57744eb | Ratio |
---|---|---|---|
Benchmark_Compress_Levels/Brotli_LevelBestCompression - B/op |
6 B/op |
0 B/op |
+∞ |
This comment was automatically generated by workflow using github-action-benchmark.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (1)
binder/form_test.go (1)
137-142
: Verifying all integer and string fields together ensures consistent binding.
These assertions comprehensively validateNames
andPosts
. The approach checks that multiple values are properly stored, including "eric," and that a fixed number of posts is parsed correctly.For formatting, consider addressing the gofumpt warning on line 142 for consistency with Go style guidelines.
🧰 Tools
🪛 golangci-lint (1.62.2)
142-142: File is not
gofumpt
-ed with-extra
(gofumpt)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
binder/form_test.go
(3 hunks)
🧰 Additional context used
🪛 golangci-lint (1.62.2)
binder/form_test.go
142-142: File is not gofumpt
-ed with -extra
(gofumpt)
🔇 Additional comments (4)
binder/form_test.go (4)
96-98
: New Post
struct introduction looks concise and effective.
The addition of this struct is aligned with the new binding logic for multipart keys. The Title
field is well-defined with a form
tag.
103-103
: Posts []Post
field addition aligns with square bracket notation changes.
This field logically complements the new Post
struct to parse an array of posts from multipart form data. To be extra robust, consider testing an empty or missing posts
key to confirm the default behavior of this field.
114-114
: Multiple values for names
thoroughly tests splitting logic.
The inclusion of "john,eric"
ensures that the functionality for splitting comma-delimited strings is properly exercised before adding "doe"
.
117-119
: Good coverage for testing array indexing of posts
.
Ensuring each indexed title (e.g., posts[0][title]
) is properly bound verifies that the new bracket notation logic works for nested keys.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 LGTM, we could add a b.RunParallel() benchmark too.
@@ -66,7 +66,27 @@ func (b *FormBinding) bindMultipart(req *fasthttp.Request, out any) error { | |||
return err | |||
} | |||
|
|||
return parse(b.Name(), out, data.Value) | |||
temp := make(map[string][]string) | |||
for key, values := range data.Value { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this part looks almost identical to the other square bracket parsings, if it were possible it would be cool if we could move this into another function and use it in all three places
query params
Lines 34 to 45 in 775e0a7
if strings.Contains(k, "[") { | |
k, err = parseParamSquareBrackets(k) | |
} | |
if b.EnableSplitting && strings.Contains(v, ",") && equalFieldType(out, reflect.Slice, k) { | |
values := strings.Split(v, ",") | |
for i := 0; i < len(values); i++ { | |
data[k] = append(data[k], values[i]) | |
} | |
} else { | |
data[k] = append(data[k], v) | |
} |
form params urlencoded
Lines 41 to 52 in 775e0a7
if strings.Contains(k, "[") { | |
k, err = parseParamSquareBrackets(k) | |
} | |
if b.EnableSplitting && strings.Contains(v, ",") && equalFieldType(out, reflect.Slice, k) { | |
values := strings.Split(v, ",") | |
for i := 0; i < len(values); i++ { | |
data[k] = append(data[k], values[i]) | |
} | |
} else { | |
data[k] = append(data[k], v) | |
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (2)
binder/mapping.go (1)
259-266
: Consider literal commas vs. delimiter-based splitting.Checking only for
strings.Contains(value, ",")
might catch legitimate commas that users do not intend as delimiters. If literal commas need to be supported, consider a more robust approach or additional flags to distinguish delimiter commas from literal commas. However, if comma-splitting is the intended behavior, this is acceptable.binder/form.go (1)
69-73
: Add tests to fully cover the comma-splitting logic.According to static analysis, lines covering the error check around comma-splitting are not exercised. A test scenario with invalid or unexpected comma usage would ensure robust coverage. Consider adding a test with malformed comma-based data to confirm the error handling.
Do you need help creating a specialized unit test for that scenario?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
binder/cookie.go
(1 hunks)binder/form.go
(2 hunks)binder/header.go
(1 hunks)binder/mapping.go
(1 hunks)binder/query.go
(1 hunks)binder/resp_header.go
(1 hunks)
🧰 Additional context used
🪛 GitHub Check: codecov/patch
binder/resp_header.go
[warning] 25-26: binder/resp_header.go#L25-L26
Added lines #L25 - L26 were not covered by tests
[warning] 34-35: binder/resp_header.go#L34-L35
Added lines #L34 - L35 were not covered by tests
binder/header.go
[warning] 24-25: binder/header.go#L24-L25
Added lines #L24 - L25 were not covered by tests
[warning] 33-34: binder/header.go#L33-L34
Added lines #L33 - L34 were not covered by tests
binder/form.go
[warning] 62-63: binder/form.go#L62-L63
Added lines #L62 - L63 were not covered by tests
🔇 Additional comments (14)
binder/query.go (1)
30-30
: Ensure bracket notation is preserved in the new formatBindData
usage.
This call looks correct for passing the EnableSplitting
flag and specifying the isQuery
parameter as true
. However, please verify that the new code properly handles square bracket notation (e.g., foo[bar]
) by adding or updating relevant tests for query parameters.
binder/cookie.go (1)
30-30
: Confirm correct cookie splitting and bracket parsing in formatBindData
.
The refactored approach centralizes data binding logic, which is good. Ensure special care is taken with bracket notation in cookie keys and that any custom splitting logic still aligns with the new function’s behaviors.
binder/header.go (4)
21-21
: Good approach to handle potential errors in a local variable.
Declaring err
ahead of the VisitAll
closure centralizes error control. This is a clean practice.
23-25
: Add test coverage for early return on header parsing errors.
Lines 24–25 remain uncovered by tests according to static analysis. Consider adding a scenario where formatBindData
fails mid-iteration, ensuring we correctly exit and skip further headers.
🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 24-25: binder/header.go#L24-L25
Added lines #L24 - L25 were not covered by tests
29-29
: Centralized data binding is clear and consistent.
Moving the logic into formatBindData
eliminates duplication. Just be sure bracketed header keys (if any occur) are tested.
32-34
: Test error return path to improve code coverage.
Similar to the above coverage gap, line 33 is flagged as untested. A negative test injecting an error from formatBindData
ensures robust coverage.
🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 33-34: binder/header.go#L33-L34
Added lines #L33 - L34 were not covered by tests
binder/resp_header.go (4)
21-21
: Consistent error handling variable initialization.
This is consistent with the rest of the binders. Centralizing err
helps maintain a clear, unified error flow.
24-26
: Add test coverage for short-circuiting on error.
Lines 25–26 are not covered. Similar to header.go
, consider testing a case where formatBindData
returns an error mid-visit, ensuring the function stops processing and exits.
🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 25-26: binder/resp_header.go#L25-L26
Added lines #L25 - L26 were not covered by tests
30-30
: Data binding logic is cleanly delegated to formatBindData
.
As with the other binders, confirm that bracket notation and splitting scenarios involving response headers are validated.
33-35
: Ensure the error return path is tested.
Lines 34–35 are untested. Please add negative tests or edge-case tests for formatBindData
failing, validating that we properly return the error without processing more headers.
🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 34-35: binder/resp_header.go#L34-L35
Added lines #L34 - L35 were not covered by tests
binder/mapping.go (1)
253-257
: Ensure bracket notation is consistently handled if error is non-nil.
Currently, if parseParamSquareBrackets
returns an error, we exit immediately. This is correct for halting further processing of malformed keys. Confirm that additional calls to formatBindData
(if any) are not made after an error is returned, to avoid partial updates to the data
map.
binder/form.go (3)
40-40
: Great use of centralized data formatting.
Using the formatBindData
function here streamlines logic by consolidating bracket notation and comma-splitting in one place. This helps reduce code duplication.
57-63
: Avoid partial updates to the temporary map when encountering errors.
When an error occurs within the loop (e.g., unmatched bracket), the function returns immediately. This prevents partial updates to temp
. Confirm that no subsequent iteration or data assignment occurs after an error is triggered to maintain consistency.
🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 62-63: binder/form.go#L62-L63
Added lines #L62 - L63 were not covered by tests
77-77
: Return statement: Good.
Returning from parse(...)
with the updated temp
map ensures consistent usage of bracket-notation keys and any split values. This addresses previous concerns about modifying maps during iteration.
func formatBindData(out any, data map[string][]string, key, value string, enableSplitting, supportBracketNotation bool) error { //nolint:revive // it's okay | ||
var err error | ||
if supportBracketNotation && strings.Contains(key, "[") { | ||
key, err = parseParamSquareBrackets(key) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
add early error return, otherwise it do the rest
Description
Fixes #3224
Will be backporting to v2 after the PR is get merged
Type of change
Checklist
Before you submit your pull request, please make sure you meet these requirements:
/docs/
directory for Fiber's documentation.Commit formatting
Please use emojis in commit messages for an easy way to identify the purpose or intention of a commit. Check out the emoji cheatsheet here: CONTRIBUTING.md