Skip to content
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

Open
wants to merge 10 commits into
base: main
Choose a base branch
from

Conversation

efectn
Copy link
Member

@efectn efectn commented Dec 6, 2024

Description

Fixes #3224

Will be backporting to v2 after the PR is get merged

Type of change

  • Enhancement (improvement to existing features and functionality)

Checklist

Before you submit your pull request, please make sure you meet these requirements:

  • Followed the inspiration of the Express.js framework for new functionalities, making them similar in usage.
  • Conducted a self-review of the code and provided comments for complex or critical parts.
  • Updated the documentation in the /docs/ directory for Fiber's documentation.
  • Added or updated unit tests to validate the effectiveness of the changes or new features.
  • Ensured that new and existing unit tests pass locally with the changes.
  • Verified that any new dependencies are essential and have been agreed upon by the maintainers/community.
  • Aimed for optimal performance with minimal allocations in the new code.
  • Provided benchmarks for the new code to analyze and improve upon.

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

@efectn efectn requested a review from a team as a code owner December 6, 2024 12:36
@efectn efectn requested review from gaby, sixcolors and ReneWerner87 and removed request for a team December 6, 2024 12:36
Copy link
Contributor

coderabbitai bot commented Dec 6, 2024

Walkthrough

The changes in this pull request enhance the multipart form data handling in the fiber package. It introduces new test cases in bind_test.go to validate the parsing of collections using square bracket notation and updates the bindMultipart method in binder/form.go to support this notation and handle comma-separated values. A new Demo struct is added to facilitate binding multiple names. The error handling for required fields and nested structures is also improved, ensuring better validation and error messaging.

Changes

File Change Summary
binder/form.go Enhanced bindMultipart method to support square bracket notation and handle comma-separated values in multipart form data.
bind_test.go Added tests for multipart form data parsing, including MultipartCollectionQueryDotNotation and MultipartCollectionQuerySquareBrackets. Introduced Demo and Person structs for binding multiple entries. Updated benchmarks for body binding.
binder/form_test.go Enhanced User struct with Posts field for binding multiple post titles, and updated related test cases.

Assessment against linked issues

Objective Addressed Explanation
Support square bracket notation in multipart form data (#3224)
Support comma-separated values in multipart form data fields (#3224)
Maintain ability to transfer binary data alongside structured form data (#3224) No explicit mention of binary data handling.

Possibly related issues

Possibly related PRs

Suggested reviewers

  • gaby
  • sixcolors
  • ReneWerner87

🐰 In the fields where data flows,
A rabbit hops, where the structure grows.
With brackets square, and commas too,
Multipart forms, we bind anew!
So let’s celebrate, with joy and cheer,
For parsing dreams are finally here! 🐇


📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ddeba87 and 3b4633e.

📒 Files selected for processing (1)
  • binder/form_test.go (3 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • binder/form_test.go

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?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR. (Beta)
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@efectn efectn added the v3 label Dec 6, 2024
@efectn efectn added this to the v3 milestone Dec 6, 2024
Copy link

codecov bot commented Dec 6, 2024

Codecov Report

Attention: Patch coverage is 80.00000% with 3 lines in your changes missing coverage. Please review.

Project coverage is 84.32%. Comparing base (57744eb) to head (3b4633e).

Files with missing lines Patch % Lines
binder/form.go 80.00% 2 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3235      +/-   ##
==========================================
- Coverage   84.40%   84.32%   -0.08%     
==========================================
  Files         116      116              
  Lines       11485    11499      +14     
==========================================
+ Hits         9694     9697       +3     
- Misses       1374     1382       +8     
- Partials      417      420       +3     
Flag Coverage Δ
unittests 84.32% <80.00%> (-0.08%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Contributor

@coderabbitai coderabbitai bot left a 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

📥 Commits

Reviewing files that changed from the base of the PR and between 89a0cd3 and 829d6cf.

📒 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)

bind_test.go Outdated Show resolved Hide resolved
bind_test.go Outdated Show resolved Hide resolved
bind_test.go Outdated Show resolved Hide resolved
bind_test.go Outdated Show resolved Hide resolved
binder/form.go Outdated Show resolved Hide resolved
Copy link
Contributor

@coderabbitai coderabbitai bot left a 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 and data.1[name])
  • Special characters in field names

Line range hint 992-1302: Overall implementation looks solid

The 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:

  1. Documenting the preferred notation in comments
  2. Adding examples in the test file showing when to use each notation
  3. 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

📥 Commits

Reviewing files that changed from the base of the PR and between 829d6cf and 3c3fa8c.

📒 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

bind_test.go Outdated Show resolved Hide resolved
@gaby gaby changed the title 🐛 bug: add square bracket notation support to BindMultipart 🐛 bug: Fix square bracket notation in Multipart FormData Dec 7, 2024
@gaby
Copy link
Member

gaby commented Dec 9, 2024

@efectn Analysis by o1-pro of the whole file.

Key Issues Identified:

  1. Inconsistent key handling in BindMultipart:
    When parsing multipart form keys containing square brackets, the code attempts to normalize them using parseParamSquareBrackets. Once a bracketed key is converted (e.g., key becomes k), the code updates data.Value[k] and deletes data.Value[key]. However, in the subsequent logic that splits values by commas, the original key is still used instead of k. This leads to an inconsistency:

    if strings.Contains(key, "[") {
        k, err := parseParamSquareBrackets(key)
        if err != nil {
            return err
        }
        data.Value[k] = values
        delete(data.Value, key)
        // After this, the logical key should be 'k', not 'key'.
    }
    
    if strings.Contains(v, ",") && equalFieldType(out, reflect.Slice, key) {
        delete(data.Value, key)
        values := strings.Split(v, ",")
        for i := 0; i < len(values); i++ {
            data.Value[key] = append(data.Value[key], values[i])
        }
    }

    Here, key should be replaced with k once the key has been normalized. Otherwise, you risk appending data to a key that no longer exists or overwriting the wrong keys. A simple fix is to reassign key = k after normalizing, ensuring that all subsequent references consistently use the updated key.

  2. Modifying the map while iterating in BindMultipart:
    The code updates data.Value (by deleting and reassigning entries) within the same for key, values := range data.Value loop. While in current Go implementations this often works without immediate panics, it's not a best practice and can lead to unpredictable behavior or future compatibility issues. A safer approach would be:

    • First, collect all necessary key/value transformations into a temporary map.
    • After the loop, apply all the collected changes at once to data.Value.
  3. Comma-splitting logic potentially overwriting data in BindMultipart:
    Consider the scenario where multiple values in values contain commas. The current code deletes the entry from data.Value and then re-appends split arrays for each comma-containing value. If more than one v contains commas, each subsequent match re-deletes and reassigns the array, possibly discarding previously processed splits from the same key. This may not be intended behavior. If the goal is to combine all comma-separated values into a single array, you may want to accumulate them first, then write them back to data.Value[key] once at the end of processing that key.

  4. Error handling inside VisitAll in Bind():
    Inside the Bind() method’s VisitAll callback, if an error occurs (e.g., in parseParamSquareBrackets), the code sets err and returns from the callback. The logic outside the callback checks if err != nil { return err } after iteration. This is correct logically, but it's important to ensure that no further processing occurs after err is set in the callback. The current code seems correct, but just be aware that any operations after setting err within the callback won't be halted until the callback returns. This is not a bug per se, just something to be cautious about.

  5. Reliance on equalFieldType and parseParamSquareBrackets correctness:
    If equalFieldType or parseParamSquareBrackets panic or do not handle unexpected input gracefully, it could lead to runtime errors. Ensure these helper functions handle all edge cases.

Summary of Primary Concerns:

  • The most significant bug is the incorrect usage of key after it has been transformed into k in the multipart parsing logic.
  • Modifying data.Value while iterating over it could cause unpredictable outcomes; better to gather changes and apply them after the loop.
  • Repeatedly deleting and reassigning keys when splitting comma-separated values can lead to unexpected loss of data if multiple values contain commas.

Copy link
Contributor

@coderabbitai coderabbitai bot left a 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 transformations

While 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

📥 Commits

Reviewing files that changed from the base of the PR and between 3c3fa8c and fa9acf8.

📒 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:

  1. Using a temporary map prevents modification during iteration
  2. Proper error handling for square bracket notation
  3. Consistent key usage after transformation
  4. 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: ⚠️ Potential issue

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.

Copy link
Contributor

@coderabbitai coderabbitai bot left a 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 issue

Add 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 issue

Add 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 issue

Fix benchmark test variable usage

The benchmark is using t instead of b 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 handling

The 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

📥 Commits

Reviewing files that changed from the base of the PR and between fa9acf8 and bf046b7.

📒 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)
+}

Copy link
Contributor

@github-actions github-actions bot left a 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.

Copy link
Contributor

@coderabbitai coderabbitai bot left a 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 validate Names and Posts. 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

📥 Commits

Reviewing files that changed from the base of the PR and between bf046b7 and ddeba87.

📒 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.

Copy link
Member

@gaby gaby left a 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: In Progress
Development

Successfully merging this pull request may close these issues.

Feature Request: Support Square Bracket Notation in Multipart Form Data
2 participants