🔥 feat: Add support for CBOR encoding #3173
Conversation
imsk17
requested review from
gaby,
sixcolors,
ReneWerner87 and
efectn
and removed request for
a team
WalkthroughThe changes in this pull request enhance the Changes
Assessment against linked issues
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
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 (
|
gaby
changed the title
gaby
changed the title
|
@imsk17 Thank you for the PR. Seems the tests are failing. The hex values dont match. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (3)
ctx.go (2)
886-902: LGTM! Consider adding a brief comment.The implementation of the
CBORmethod looks good. It follows the pattern of similar methods likeJSON, handles errors appropriately, and allows for custom content types. The use ofSetBodyRawis efficient for setting the response body.Consider adding a brief comment explaining the purpose of this method, similar to other methods in this file. For example:
// CBOR converts any interface or string to CBOR encoded bytes and sets it as the response body. // If the ctype parameter is given, it sets the Content-Type header to the provided value. // Otherwise, it sets the Content-Type header to "application/cbor". func (c *DefaultCtx) CBOR(data any, ctype ...string) error { // ... (existing implementation) }
Line range hint
1048-1066: Consider improving error handling in the JSON methodFor consistency with the newly added
CBORmethod, consider updating theJSONmethod to return an error. This would allow for better error handling when JSON encoding fails.Here's a suggested modification to the
JSONmethod:-func (c *DefaultCtx) JSON(data any, ctype ...string) error { +func (c *DefaultCtx) JSON(data any, ctype ...string) error { raw, err := c.app.config.JSONEncoder(data) if err != nil { - return err + return fmt.Errorf("failed to encode JSON: %w", err) } c.fasthttp.Response.SetBodyRaw(raw) if len(ctype) > 0 { c.fasthttp.Response.Header.SetContentType(ctype[0]) } else { c.fasthttp.Response.Header.SetContentType(MIMEApplicationJSON) } return nil }This change would make the error handling more informative and consistent with the new
CBORmethod.app.go (1)
321-334: Ensure comments for CBOR encoder and decoder fields are clear and consistentThe comments for
CBOREncoderandCBORDecoderin theConfigstruct could be improved for clarity and consistency with existing documentation comments. Consider revising the comments to match the style of other encoder/decoder fields.Apply this diff to adjust the comments:
321,325c321,325 - // When set by an external client of Fiber it will use the provided implementation of a - // CBORMarshal - // - // Allowing for flexibility in using another cbor library for encoding - // Default: cbor.Marshal + // When set by an external client of Fiber, it will use the provided implementation of a + // CBORMarshal. + // + // Allowing for flexibility in using another CBOR library for encoding. + // Default: cbor.MarshalSimilarly, adjust the comments for
CBORDecoder:328,333c328,333 - // When set by an external client of Fiber it will use the provided implementation of a - // CBORUnmarshal - // - // Allowing for flexibility in using another cbor library for decoding - // Default: cbor.Unmarshal + // When set by an external client of Fiber, it will use the provided implementation of a + // CBORUnmarshal. + // + // Allowing for flexibility in using another CBOR library for decoding. + // Default: cbor.Unmarshal
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (2)
go.modis excluded by!**/*.modgo.sumis excluded by!**/*.sum,!**/*.sum
📒 Files selected for processing (6)
- app.go (3 hunks)
- constants.go (1 hunks)
- ctx.go (1 hunks)
- ctx_interface_gen.go (1 hunks)
- ctx_test.go (2 hunks)
- middleware/cache/manager_msgp.go (2 hunks)
🧰 Additional context used
🔇 Additional comments (14)
middleware/cache/manager_msgp.go (3)
55-57: Approve: Improved nil handling in headers mapThis change enhances the robustness of the
DecodeMsgmethod by ensuring that no nil values are stored in theheadersmap. By initializing nil byte slices to empty slices, it maintains consistency in the data structure and potentially prevents nil pointer dereferences in code that uses these headers. This is a good practice for handling potentially nil values.
273-275: Approve: Consistent nil handling in UnmarshalMsgThis change in the
UnmarshalMsgmethod mirrors the improvement made inDecodeMsg. It ensures consistent handling of nil values across different serialization operations, maintaining data integrity and preventing potential issues with nil values in theheadersmap. This consistency is crucial and demonstrates a thorough approach to the nil-value handling enhancement.
55-57: Summary: Improved robustness in cache serializationThese changes enhance the reliability of the caching mechanism by ensuring consistent handling of nil values in the
headersmap during both decoding and unmarshaling operations. While not directly related to CBOR encoding, this improvement aligns with the PR's objective of enhancing data handling capabilities within the framework. It provides a more robust foundation for interacting with various data formats, including CBOR, by ensuring that the underlying data structures are always in a consistent state.The nil-to-empty-slice conversion simplifies error handling for consumers of this cache data, as they can now assume that header values are always valid byte slices. This could lead to more predictable behavior and easier integration with new features like CBOR encoding.
While there might be a negligible performance impact due to the additional nil checks and potential memory allocations for empty slices, the benefits in terms of increased robustness and consistency outweigh this minor concern.
Also applies to: 273-275
constants.go (2)
26-26: LGTM: Correct MIME type constant for CBOR addedThe addition of
MIMEApplicationCBORconstant with the value"application/cbor"is correct and consistent with the existing MIME type constants in the file. This constant will be useful for setting the appropriate Content-Type header when sending CBOR-encoded responses.
26-26: Summary: Minimal, focused change for CBOR supportThe addition of the
MIMEApplicationCBORconstant is the only change in this file. It's a minimal and focused modification that supports the PR's objective of adding CBOR encoding capabilities. The change maintains backward compatibility and follows existing patterns in the codebase.ctx_interface_gen.go (3)
166-170: New CBOR method added to Ctx interfaceThe addition of the
CBORmethod to theCtxinterface is consistent with the existing pattern for other data serialization methods likeJSONandXML. This enhancement allows for encoding response bodies in CBOR format, which aligns with the PR objectives.A few observations:
- The method signature
CBOR(data any, ctype ...string) erroris consistent with other serialization methods in the interface.- The comment describes the functionality and default behavior for the Content-Type header, which is helpful for developers.
To ensure consistency across the codebase, let's verify the implementation of this method:
#!/bin/bash # Search for the CBOR method implementation rg -p 'func \(c \*DefaultCtx\) CBOR\(' --type go
Line range hint
1-170: Summary of changes to ctx_interface_gen.goThe changes to this file are minimal but significant:
- A new
CBORmethod has been added to theCtxinterface, enhancing the framework's serialization capabilities.- The addition is consistent with existing patterns and doesn't break the interface contract.
Overall, this change successfully implements part of the PR's objective to allow encoding response bodies in CBOR format. The integration is clean and follows the established conventions of the
fiberpackage.To ensure full implementation:
Let's check for any related configuration options or utilities added for CBOR support:
#!/bin/bash # Search for CBOR-related additions in other files rg -p 'CBOR' --type go
Line range hint
1-170: Overall interface consistency and documentation considerationsThe addition of the
CBORmethod to theCtxinterface is well-integrated and consistent with the existing design. It follows the same pattern as other serialization methods likeJSON,JSONP, andXML.Considerations:
- The interface remains backwards-compatible as the new method doesn't alter existing method signatures.
- The placement of the
CBORmethod alongside other serialization methods enhances discoverability for developers.Consider updating the package documentation and examples to include usage of the new CBOR functionality. This will help developers understand how to utilize this new feature effectively.
Let's check if the documentation has been updated:
ctx.go (1)
Line range hint
1-3140: Overall, the changes look good with minor suggestions for improvementThe addition of the
CBORmethod to theDefaultCtxstruct is well-implemented and consistent with the existing codebase. The suggested improvements (adding a comment to theCBORmethod and updating theJSONmethod's error handling) would enhance the code's documentation and consistency.No other significant issues were found in the surrounding code. The file maintains a good structure and follows consistent patterns throughout.
app.go (2)
26-26: Import statement added appropriatelyThe import of
github.com/fxamacker/cbor/v2is necessary to support CBOR encoding and decoding functionalities.
552-557: Default CBOR encoder and decoder are correctly initializedThe default CBOR encoder and decoder are properly set to
cbor.Marshalandcbor.Unmarshalif they are not provided in the configuration, ensuring consistent behavior.ctx_test.go (3)
15-15: Import of "encoding/hex" is appropriateThe addition of
"encoding/hex"to the imports is necessary for encoding CBOR outputs to hex strings in the tests.
3576-3631: CBOR test functions are well implementedThe
Test_Ctx_CBORfunction provides comprehensive tests for the CBOR encoding functionality. It covers various cases including complex numbers, different data types, custom content types, empty values, and custom CBOR encoders. The tests are well-structured and follow existing patterns in the codebase.
3633-3655: Benchmark function for CBOR encoding is properly structuredThe
Benchmark_Ctx_CBORfunction effectively measures the performance of CBOR encoding. It aligns with the standard benchmarking practices used in the codebase, ensuring consistency and reliability of benchmark results.
|
Yea, I fixed that flaky test. |
Thanks! 💪 |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3173 +/- ##
==========================================
- Coverage 82.76% 82.53% -0.24%
==========================================
Files 114 115 +1
Lines 11149 11210 +61
==========================================
+ Hits 9228 9252 +24
- Misses 1521 1556 +35
- Partials 400 402 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
|
@imsk17 Can you add a smalk section in https://github.com/gofiber/fiber/blob/main/docs/whats_new.md explaining the new feature. This will be used in the future to showcase Fiber v2 vs V3 |
|
Done. |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (5)
docs/whats_new.md (5)
199-200: Consider expanding the CBOR documentationThe introduction of CBOR support is a significant feature that aligns well with the PR objectives. To ensure users can fully leverage this new capability, consider expanding the documentation with:
- A brief explanation of what CBOR is and its benefits.
- An example of how to use the new
CBORmethod.- Any performance considerations or best practices for using CBOR in Fiber.
This additional information would help users understand and adopt the new feature more easily.
Also applies to: 213-213
Line range hint
76-91: Enhance explanation of Router changesThe updates to the Router interface, particularly the changes to HTTP method registration and the new Route chaining, are significant improvements. To help users better understand and appreciate these changes, consider:
- Explaining the benefits of making the handler mandatory in the method signatures (e.g., improved type safety, clearer API).
- Providing a brief comparison of the old and new Route chaining syntax, highlighting how it improves code readability and maintainability.
- Adding a note on any potential breaking changes these updates might cause for existing codebases.
These additions would provide more context and help users understand why these changes were made and how they can benefit from them.
Also applies to: 96-102
🧰 Tools
🪛 LanguageTool
[uncategorized] ~203-~203: The official spelling of this programming framework is “Express.js”.
Context: ...ions. ### new methods - AutoFormat -> ExpressJs like - Host -> ExpressJs like - Port ->...(NODE_JS)
Line range hint
252-254: Expand the Client package sectionThe Client package rebuild seems to be a major update in Fiber v3. To give users a better understanding of these changes, consider:
- Listing a few key new features or improvements (e.g., Cookiejar, request/response hooks) with brief explanations.
- Providing a simple before-and-after code example to illustrate how the usage of the Client package has changed.
- Mentioning any performance improvements or changes in behavior that users should be aware of.
This additional information would help users quickly grasp the significance of the Client package updates and how they might affect their existing code.
🧰 Tools
🪛 LanguageTool
[uncategorized] ~203-~203: The official spelling of this programming framework is “Express.js”.
Context: ...ions. ### new methods - AutoFormat -> ExpressJs like - Host -> ExpressJs like - Port ->...(NODE_JS)
Line range hint
321-326: Clarify middleware changes and migration stepsThe updates to various middlewares represent significant changes in Fiber v3. To ensure a smooth transition for users, consider:
For the Filesystem middleware removal:
- Explain the rationale behind merging it into the Static middleware.
- Provide a more detailed example of how to migrate from Filesystem to Static, covering common use cases.
For the Monitor middleware move to Contrib:
- Explain why this change was made (e.g., to keep the core lighter, to allow for more frequent updates).
- Provide clear instructions on how to install and import the Contrib package.
For other middleware updates (e.g., Adaptor, CORS):
- Highlight any potential breaking changes.
- Provide before-and-after examples for common configurations.
These additions would help users understand the impact of these changes and how to update their existing code effectively.
Also applies to: 410-416, 495-507
🧰 Tools
🪛 LanguageTool
[uncategorized] ~203-~203: The official spelling of this programming framework is “Express.js”.
Context: ...ions. ### new methods - AutoFormat -> ExpressJs like - Host -> ExpressJs like - Port ->...(NODE_JS)
Line range hint
509-515: Enhance the migration guide structure and contentThe migration guide is a crucial resource for users upgrading to Fiber v3. To make it even more effective, consider the following improvements:
- Add a brief introduction explaining the scope of changes in v3 and who needs to pay attention to which sections.
- Include a "Quick Start" section for users with simpler applications, highlighting the most common and critical changes.
- For each major change, provide:
- A brief explanation of why the change was made.
- A complete before-and-after code example.
- Any gotchas or common pitfalls to watch out for during migration.
- Add a "Troubleshooting" section addressing common issues users might encounter during the upgrade process.
- Consider adding a "Deprecation Timeline" for any features that are being phased out but not immediately removed in v3.
These enhancements would make the migration guide more user-friendly and comprehensive, helping to ensure a smoother transition for all Fiber users.
🧰 Tools
🪛 LanguageTool
[uncategorized] ~203-~203: The official spelling of this programming framework is “Express.js”.
Context: ...ions. ### new methods - AutoFormat -> ExpressJs like - Host -> ExpressJs like - Port ->...(NODE_JS)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
- docs/whats_new.md (2 hunks)
🧰 Additional context used
🔇 Additional comments (1)
docs/whats_new.md (1)
Line range hint
1-515: Overall, a comprehensive and well-structured document with room for enhancementThis "What's New in v3" document provides a thorough overview of the changes and improvements in Fiber v3. It covers a wide range of topics including app configuration, routing, context handling, client package updates, and middleware changes. The inclusion of a migration guide is particularly helpful for users upgrading from v2.
To further improve this document, consider:
- Expanding on new features like CBOR support with more detailed explanations and examples.
- Providing more context for significant changes, such as those in the Router interface, to help users understand the benefits and potential impacts.
- Enhancing the Client package section with more specific details about new features and improvements.
- Clarifying the middleware changes, particularly for removed or relocated middlewares, with more detailed migration instructions.
- Structuring the migration guide to be more user-friendly, including a quick start section, more comprehensive examples, and a troubleshooting guide.
These enhancements would make the document even more valuable for Fiber users, ensuring a smooth transition to v3 and helping them leverage all the new features and improvements effectively.
🧰 Tools
🪛 LanguageTool
[uncategorized] ~203-~203: The official spelling of this programming framework is “Express.js”.
Context: ...ions. ### new methods - AutoFormat -> ExpressJs like - Host -> ExpressJs like - Port ->...(NODE_JS)
|
@imsk17 I found one more place CBOR is missing. In the bind/binder which have support for JSON and XML See here: |
|
Right. I will have a look. |
|
@imsk17 These places too |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (4)
docs/whats_new.md (4)
199-200: Enhance CBOR documentation with examples and configuration options.The CBOR feature introduction would benefit from:
- Code examples showing usage
- Configuration options (if any)
- Performance characteristics compared to JSON/XML
Add a code example like this:
// Example CBOR usage app.Get("/", func(c *fiber.Ctx) error { data := map[string]interface{}{ "message": "Hello, World!", "number": 42, } return c.CBOR(data) })
213-213: Cross-reference CBOR method in Context section.The CBOR method listing should include a link to its detailed API documentation and mention any available configuration options.
Update the line to:
-CBOR -> for CBOR encoding +CBOR -> for CBOR encoding (see [CBOR API documentation](./api/ctx.md#cbor))
Line range hint
1-24: Consider adding version compatibility matrix.The introduction section would benefit from a clear compatibility matrix showing:
- Go version requirements
- Breaking changes overview
- Deprecation timeline for v2
Add a compatibility matrix like:
| Fiber Version | Go Version | Status | |--------------|------------|-------------| | v3.x | ≥ 1.22 | Current | | v2.x | ≥ 1.17 | Maintenance |🧰 Tools
🪛 LanguageTool
[uncategorized] ~203-~203: The official spelling of this programming framework is “Express.js”.
Context: ...ions. ### new methods - AutoFormat -> ExpressJs like - Host -> ExpressJs like - Port ->...(NODE_JS)
Line range hint
12-24: Update table of contents to match actual content.The table of contents is missing some sections that are present in the document:
- Drop for old Go versions
- Generic functions
Update the table of contents to include all sections and maintain consistent ordering with the document body.
🧰 Tools
🪛 LanguageTool
[uncategorized] ~203-~203: The official spelling of this programming framework is “Express.js”.
Context: ...ions. ### new methods - AutoFormat -> ExpressJs like - Host -> ExpressJs like - Port ->...(NODE_JS)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
- docs/whats_new.md (2 hunks)
🔇 Additional comments (1)
docs/whats_new.md (1)
Line range hint
199-213: Verify CBOR implementation details in codebase.Let's verify the CBOR implementation details to ensure documentation accuracy.
✅ Verification successful
CBOR implementation is properly documented and implemented
The documentation accurately reflects the CBOR implementation in the codebase. The verification shows:
- CBOR is fully implemented using the
github.com/fxamacker/cbor/v2package- The implementation includes:
CBOR()method in the context with proper content type handling- Configurable
CBOREncoder/CBORDecoderinterfaces- Comprehensive test coverage in
ctx_test.go- Default MIME type constant
MIMEApplicationCBORThe feature is well-tested, properly documented, and follows the same patterns as other response formats in the framework.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for CBOR-related code echo "Searching for CBOR method implementation..." ast-grep --pattern 'func $_(c *fiber.Ctx) error { $$$ c.CBOR($$$) $$$ }' echo "Searching for CBOR tests..." rg -l "TestCBOR" -g "**/*_test.go" echo "Searching for CBOR configuration..." rg "CBOR.*Config"Length of output: 378
Script:
#!/bin/bash # Let's try different search patterns to find CBOR implementation # Search for CBOR-related files and functions echo "Searching for CBOR in all files..." rg -i "cbor" -A 5 -B 5 # Search for CBOR type or interface definitions echo "Searching for CBOR type definitions..." ast-grep --pattern 'type $_ struct { $$$ CBOR $$$ $$$ }' # Search for CBOR method declarations echo "Searching for CBOR method declarations..." ast-grep --pattern 'func (c *Ctx) CBOR($$$) error' # Look for imports of CBOR-related packages echo "Searching for CBOR-related imports..." rg "import.*cbor"Length of output: 10999
🧰 Tools
🪛 LanguageTool
[uncategorized] ~203-~203: The official spelling of this programming framework is “Express.js”.
Context: ...ions. ### new methods - AutoFormat -> ExpressJs like - Host -> ExpressJs like - Port ->...(NODE_JS)
|
@imsk17 Any updates on this? |
|
Hi, Done with the tests. |
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Outside diff range and nitpick comments (11)
binder/cbor.go (1)
1-15: Consider adding unit tests and documentation.As this is a new binding implementation, please ensure:
- Add comprehensive unit tests covering both success and error cases
- Add godoc comments explaining the binding's purpose and usage
- Update the framework's documentation to include CBOR binding examples
- Consider adding benchmarks to compare with other binding implementations
Would you like me to help generate:
- Unit test cases?
- Documentation examples?
- Benchmark tests?
client/response.go (1)
78-81: Enhance method documentation for better clarity.The implementation looks good and follows the established pattern of other unmarshal methods. Consider enhancing the documentation to provide more details about the CBOR unmarshaling process and any potential errors that might be returned.
-// CBOR method will unmarshal body to cbor. +// CBOR method unmarshals the response body as CBOR into the given value. +// It uses the client's CBOR unmarshaler to decode the response body. +// Returns an error if the unmarshaling fails.bind.go (1)
123-128: Add documentation and ensure test coverage.Please consider the following improvements:
- Add documentation comments for the CBOR method explaining:
- Purpose and usage
- Any specific CBOR encoding considerations
- Example usage if helpful
- Ensure comprehensive test coverage in
bind_test.go:
- Basic CBOR binding
- Error cases
- Performance benchmarks comparing with JSON
Example documentation:
+// CBOR binds CBOR-encoded body data into the provided struct. +// The binding uses the application's configured CBORDecoder for custom decoding if provided. func (b *Bind) CBOR(out any) error {client/hooks.go (1)
133-134: Consider setting Accept header for consistencyWhile the CBOR case correctly sets the Content-Type header, consider setting the Accept header to match the pattern used in the JSON case for consistency:
case cborBody: req.RawRequest.Header.SetContentType(applicationCBOR) + req.RawRequest.Header.Set(headerAccept, applicationCBOR)client/client.go (2)
155-175: Fix documentation comments referencing XML instead of CBORThe documentation comments for CBOR methods incorrectly reference XML. This should be updated to maintain accuracy.
Update the comments as follows:
-// CBORMarshal returns xml marshal function in Core. +// CBORMarshal returns CBOR marshal function in Core. -// SetCBORMarshal Set xml encoder. +// SetCBORMarshal Set CBOR encoder. -// CBORUnmarshal returns xml unmarshal function in Core. +// CBORUnmarshal returns CBOR unmarshal function in Core. -// SetCBORUnmarshal Set xml decoder. +// SetCBORUnmarshal Set CBOR decoder.
Line range hint
607-608: Consider adding CBOR support to Config structThe
Configstruct andsetConfigToRequestfunction currently default to JSON serialization for the Body field. Consider adding support for CBOR serialization to maintain consistency with the new CBOR functionality.Consider adding a field to specify the serialization format:
type Config struct { Body any + // BodyFormat specifies the serialization format (e.g., "json", "xml", "cbor") + BodyFormat string // ... rest of the fields }Then update
setConfigToRequest:if cfg.Body != nil { + switch cfg.BodyFormat { + case "cbor": + req.SetCBOR(cfg.Body) + case "xml": + req.SetXML(cfg.Body) + default: req.SetJSON(cfg.Body) + } return }client/request.go (2)
341-345: Add documentation comments for consistency.Other methods in this file include documentation comments. Consider adding a comment to describe the CBOR functionality:
+// SetCBOR method sets CBOR body in request. func (r *Request) SetCBOR(v any) *Request {
341-345: LGTM! Consider adding validation for better error handling.The implementation correctly follows the established pattern. However, consider adding validation to ensure the input can be properly encoded to CBOR:
func (r *Request) SetCBOR(v any) *Request { + if v == nil { + return r + } r.body = v r.bodyType = cborBody return r }bind_test.go (3)
15-15: Use an import alias for clarityConsider adding an alias for the
cborpackage to improve code readability and avoid potential naming conflicts.Apply this diff to add an import alias:
- "github.com/fxamacker/cbor/v2" + cbor "github.com/fxamacker/cbor/v2"
1103-1131: Handle errors consistently in benchmarksIn the
Benchmark_Bind_Body_CBORfunction, consider usingb.Fatalfinstead ofb.Errorto halt the benchmark immediately if marshalling fails. This ensures that the benchmark does not continue running with invalid data.Apply this diff for consistent error handling:
body, err := cbor.Marshal(&Demo{Name: "john"}) if err != nil { - b.Error(err) + b.Fatalf("Failed to marshal CBOR data: %v", err) }
1751-1760: Avoid duplicating error handling codeExtract the CBOR marshalling and error handling into a helper function to reduce code duplication and improve maintainability.
Create a helper function:
func marshalCBOR(t *testing.T, v interface{}) []byte { enc, err := cbor.Marshal(v) if err != nil { t.Fatal(err) } return enc }Modify your test code to use the helper function:
- cb, err := cbor.Marshal(&Request{ + cb := marshalCBOR(t, &Request{ BodyParam: "body_param", -}) -if err != nil { - t.Error(err) -} +})Update the call to
testDecodeParser:- testDecodeParser(MIMEApplicationCBOR, string(cb)) + testDecodeParser(MIMEApplicationCBOR, cb)Ensure
testDecodeParseraccepts a byte slice:-func testDecodeParser(contentType, body string) { +func testDecodeParser(contentType string, body []byte) {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (9)
bind.go(2 hunks)bind_test.go(4 hunks)binder/binder.go(1 hunks)binder/cbor.go(1 hunks)client/client.go(2 hunks)client/client_test.go(2 hunks)client/hooks.go(3 hunks)client/request.go(2 hunks)client/response.go(1 hunks)
🔇 Additional comments (11)
binder/cbor.go (2)
7-7: LGTM! Clean type definition.
The empty struct is an appropriate choice for a stateless binding implementation.
13-15: 🛠️ Refactor suggestion
Consider adding input validation.
The Bind method directly passes the input to the decoder without any validation. Consider adding checks for:
- nil body
- empty body
- nil decoder function
- nil output parameter
Here's a suggested implementation:
func (*cborBinding) Bind(body []byte, cborDecoder utils.CBORUnmarshal, out any) error {
+ if len(body) == 0 {
+ return nil
+ }
+ if cborDecoder == nil {
+ return fmt.Errorf("cbor decoder is nil")
+ }
+ if out == nil {
+ return fmt.Errorf("output parameter is nil")
+ }
return cborDecoder(body, out)
}#!/bin/bash
# Description: Check how other binders handle validation
# Test: Look for similar validation patterns in other binders
rg -A 5 'func.*Bind.*\(.*\).*error' binder/binder/binder.go (2)
23-23: LGTM! The CBORBinder addition follows the established pattern.
The new CBORBinder variable is correctly initialized and placed logically with other data format binders.
23-23: Verify the cborBinding type implementation.
Let's ensure the cborBinding type is properly implemented with the necessary methods.
client/response.go (1)
78-81: Verify client's CBOR unmarshal implementation.
The method relies on client.cborUnmarshal. Let's verify its implementation to ensure proper CBOR support.
✅ Verification successful
CBOR implementation is properly supported and configured
The codebase has comprehensive CBOR support with proper implementation:
- The client uses
fxamacker/cbor/v2library for CBOR encoding/decoding - CBOR functionality is properly initialized in the client:
cborUnmarshalis a configurable field in the Client struct- Default CBOR decoder is set to
cbor.Unmarshalif not explicitly configured - Custom CBOR decoder can be set via
SetCBORUnmarshalmethod
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for the existence and implementation of cborUnmarshal in the Client struct
# Search for cborUnmarshal definition
echo "Searching for cborUnmarshal implementation..."
ast-grep --pattern 'func (c *Client) cborUnmarshal($_, $_) error'
# Search for CBOR-related imports
echo "Checking for CBOR-related imports..."
rg 'import.*cbor'
Length of output: 271
Script:
#!/bin/bash
# Let's try a broader search for CBOR-related code and implementations
# Search for any CBOR-related function definitions
echo "Searching for CBOR-related function implementations..."
ast-grep --pattern 'func $_($$$) $_($$$) {
$$$
cbor$$$
$$$
}'
# Search for any CBOR usage in the codebase
echo "Searching for CBOR usage in the codebase..."
rg -i "cbor" -A 3
# Search for unmarshal-related functions in client
echo "Searching for unmarshal functions in client..."
fd -e go -x grep -l "unmarshal" {} \; | xargs rg "func.*[Uu]nmarshal"
Length of output: 12701
bind.go (2)
192-193: Verify CBOR MIME type constant definition.
The implementation correctly handles CBOR content type in the Body method.
Let's verify the MIME type constant:
#!/bin/bash
# Description: Verify CBOR MIME type constant definition and usage
# Expected: Should find MIMEApplicationCBOR constant definition with value "application/cbor"
# Search for MIMEApplicationCBOR constant definition
rg "MIMEApplicationCBOR.*=.*\"application/cbor\""
# Search for other usages of this constant
rg "MIMEApplicationCBOR"123-128: Implementation looks good and follows established patterns.
The CBOR binding implementation correctly follows the same patterns as JSON and XML bindings, including proper error handling and struct validation.
Let's verify the CBORDecoder initialization:
✅ Verification successful
Based on the search results, I can now provide a final response since I have found sufficient evidence about the CBOR decoder initialization:
CBORDecoder is properly initialized with default implementation
The implementation is verified to be correct:
- CBORDecoder is defined in the Config struct with type
utils.CBORUnmarshal - Default initialization is handled in app.go:
if app.config.CBORDecoder == nil { app.config.CBORDecoder = cbor.Unmarshal } - This follows the same pattern as other decoders (JSON, XML) in the framework
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify CBORDecoder initialization in app.go
# Expected: Should find CBORDecoder initialization in Config struct and default configuration
# Search for CBORDecoder in Config struct and its initialization
rg -A 5 "CBORDecoder"
Length of output: 485
Script:
#!/bin/bash
# Let's search for CBORDecoder in the codebase
rg -A 5 "CBORDecoder"
# Also search for CBOR-related configuration
ast-grep --pattern 'type Config struct {
$$$
CBORDecoder $_
$$$
}'
# Check for any default CBOR decoder initialization
rg -A 5 "func New|func Config"
Length of output: 35440
client/hooks.go (2)
26-26: LGTM: CBOR MIME type constant follows conventions
The applicationCBOR constant correctly uses the standard MIME type "application/cbor" as specified in RFC 8949 and follows the existing naming pattern.
195-200: Verify CBOR marshaling implementation
The CBOR case follows the established pattern for body parsing, but let's verify the implementation of the referenced cborMarshal function.
✅ Verification successful
Based on the search results, I can now generate the final response since I have found sufficient evidence about the CBOR implementation:
CBOR marshaling implementation is properly integrated
The codebase shows that CBOR support is well-implemented:
- The
cborMarshalfunction is available through the client'sCBORMarshal()method - CBOR marshaling uses the
github.com/fxamacker/cbor/v2package - Default CBOR marshaling is set via
c.config.CBOREncoder = cbor.Marshal - Content type is properly set to
application/cbor
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the implementation of cborMarshal function
# Expected: Should find the implementation of cborMarshal in the client package
# Search for cborMarshal implementation
echo "Searching for cborMarshal implementation..."
rg -p "func.*cborMarshal" --type go
# Search for CBOR-related imports to verify the marshaling library
echo "Checking CBOR-related imports..."
rg "import.*cbor" --type go
Length of output: 239
Script:
#!/bin/bash
# Let's try a broader search for CBOR-related code and the cborMarshal method
# Search for any CBOR-related code
echo "Searching for any CBOR references..."
rg -i "cbor" --type go -A 5 -B 5
# Search for method definitions in the client struct
echo "Searching for client struct methods..."
ast-grep --pattern 'func (c *Client) $_($$$) $$$'
# Look for any marshal-related functions
echo "Searching for marshal-related functions..."
rg "func.*[Mm]arshal" --type go
Length of output: 39240
client/request.go (1)
37-37: LGTM! The new bodyType constant follows the established pattern.
The cborBody constant is correctly added to the bodyType enum, maintaining consistency with the existing implementation.
client/client_test.go (1)
6-6: LGTM!
The encoding/hex import is correctly placed and necessary for CBOR test cases.
binder/cbor.go
Outdated
| func (*cborBinding) Name() string { | ||
| return "json" | ||
| } |
There was a problem hiding this comment.
Fix incorrect binding name.
The Name() method returns "json" which is incorrect for a CBOR binding. This could cause confusion and potential issues with binding selection.
Apply this fix:
func (*cborBinding) Name() string {
- return "json"
+ return "cbor"
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| func (*cborBinding) Name() string { | |
| return "json" | |
| } | |
| func (*cborBinding) Name() string { | |
| return "cbor" | |
| } |
bind_test.go
Outdated
| t.Run("CBOR", func(t *testing.T) { | ||
| enc, err := cbor.Marshal(&Demo{Name: "john"}) | ||
| if err != nil { | ||
| t.Error(err) | ||
| } | ||
| str := string(enc) | ||
| testDecodeParser(t, MIMEApplicationCBOR, str) | ||
| }) |
There was a problem hiding this comment.
Avoid converting CBOR binary data to a string
CBOR data is binary, and converting it to a string can lead to data corruption or unexpected behavior. Modify testDecodeParser to accept a byte slice instead of a string to handle binary data properly.
Refactor testDecodeParser to accept []byte for the body parameter:
-func testDecodeParser(t *testing.T, contentType, body string) {
+func testDecodeParser(t *testing.T, contentType string, body []byte) {
t.Helper()
c := app.AcquireCtx(&fasthttp.RequestCtx{})
c.Request().Header.SetContentType(contentType)
- c.Request().SetBody([]byte(body))
+ c.Request().SetBody(body)
c.Request().Header.SetContentLength(len(body))
d := new(Demo)
require.NoError(t, c.Bind().Body(d))
require.Equal(t, "john", d.Name)
}Update the test case to pass the byte slice directly:
- str := string(enc)
- testDecodeParser(t, MIMEApplicationCBOR, str)
+ testDecodeParser(t, MIMEApplicationCBOR, enc)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| t.Run("CBOR", func(t *testing.T) { | |
| enc, err := cbor.Marshal(&Demo{Name: "john"}) | |
| if err != nil { | |
| t.Error(err) | |
| } | |
| str := string(enc) | |
| testDecodeParser(t, MIMEApplicationCBOR, str) | |
| }) | |
| t.Run("CBOR", func(t *testing.T) { | |
| enc, err := cbor.Marshal(&Demo{Name: "john"}) | |
| if err != nil { | |
| t.Error(err) | |
| } | |
| testDecodeParser(t, MIMEApplicationCBOR, enc) | |
| }) |
|
@imsk17 Can you fix the merge conflict with go.mod There's a few issues raised by CodeRabbit. For ex in binder it returns JSON instead of cbor. |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (2)
ctx_test.go (2)
3619-3679: Consider expanding test coverage for CBOR encodingThe test cases look good but could be enhanced for more thorough coverage:
- Add test cases for complex nested structures and arrays
- Add test cases for all primitive types (bool, int8/16/32/64, uint8/16/32/64, float32/64)
- Add test cases for concurrent encoding to verify thread safety
- Add test cases for handling nil values in nested structures
Example test case for nested structure:
type NestedStruct struct { Name string Age int IsActive bool Tags []string Metadata map[string]interface{} } data := NestedStruct{ Name: "John", Age: 30, IsActive: true, Tags: []string{"user", "admin"}, Metadata: map[string]interface{}{ "lastLogin": time.Now(), "visits": 42, }, } err := c.CBOR(data)
3681-3702: Consider enhancing benchmark coverageThe benchmark is good but could be expanded to:
- Add benchmarks for different payload sizes
- Add benchmarks comparing against JSON encoding
- Add parallel benchmarks to test concurrent performance
- Add benchmarks for custom encoder scenarios
func Benchmark_Ctx_CBOR_Parallel(b *testing.B) { app := New() data := SomeStruct{ Name: "Grame", Age: 20, } b.RunParallel(func(pb *testing.PB) { c := app.AcquireCtx(&fasthttp.RequestCtx{}) for pb.Next() { _ = c.CBOR(data) } }) } func Benchmark_Ctx_CBOR_Large(b *testing.B) { app := New() c := app.AcquireCtx(&fasthttp.RequestCtx{}) data := generateLargeStruct() // Generate large test data b.ReportAllocs() b.ResetTimer() for n := 0; n < b.N; n++ { _ = c.CBOR(data) } }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
go.modis excluded by!**/*.mod
📒 Files selected for processing (4)
app.go(3 hunks)ctx.go(1 hunks)ctx_interface_gen.go(1 hunks)ctx_test.go(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- ctx.go
- ctx_interface_gen.go
🔇 Additional comments (4)
app.go (4)
26-26: LGTM! Good choice of CBOR library.
The fxamacker/cbor library is a well-maintained and widely-used implementation of CBOR for Go.
321-334: LGTM! Well-structured Config additions.
The new CBOR configuration fields follow the established pattern of existing encoder/decoder fields. The documentation is clear and the types allow for custom implementations, maintaining flexibility.
552-557: LGTM! Proper initialization of CBOR encoders/decoders.
The default initialization follows the established pattern and uses appropriate default implementations from the CBOR library.
321-334: Verify complete CBOR integration across the framework.
While the core CBOR support is well implemented, ensure that CBOR handling is consistently implemented across all necessary components.
Also applies to: 552-557
✅ Verification successful
CBOR integration is complete and well-implemented across the framework
The verification shows comprehensive CBOR support across all necessary components:
- CBOR binding implementation exists in
binder/cbor.go - CBOR binding method is properly integrated in
bind.go - CBOR response method is available in
ctx.go - CBOR support is present in client components
- The implementation follows the same pattern as other formats (JSON, XML) with consistent integration across binding, context, and client layers
The framework provides complete CBOR support with proper integration across all required components, matching the implementation pattern of other supported formats.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for potential missing CBOR implementations in related files
# Test 1: Check for files that handle JSON/XML but might be missing CBOR
echo "Files that might need CBOR support:"
rg -l "func.*JSON|func.*XML" | grep -v "app.go"
# Test 2: Specifically check bind/binder files as mentioned in PR comments
echo -e "\nChecking bind/binder files:"
rg -l "JSON|XML" bind/
Length of output: 479
Script:
#!/bin/bash
# Let's analyze the CBOR integration more thoroughly
# Check for CBOR-related code in bind and binder directories
echo "=== Checking CBOR implementations ==="
rg -l "CBOR"
# Check specific binding implementations
echo -e "\n=== Checking binder implementations ==="
fd -t f ".*\\.go$" binder/
# Look for content in bind.go to understand current binding mechanisms
echo -e "\n=== Analyzing bind.go content ==="
rg "func.*Bind|type.*Binder" bind.go -A 5
# Check ctx.go for CBOR-related methods
echo -e "\n=== Checking ctx.go for CBOR methods ==="
rg "func.*CBOR" ctx.go
Length of output: 3804
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (3)
client/client.go (2)
156-176: Fix method documentation to correctly reference CBOR.The comments incorrectly reference "xml" instead of "cbor". Please update the documentation:
-// CBORMarshal returns xml marshal function in Core. +// CBORMarshal returns CBOR marshal function in Core. -// SetCBORMarshal Set xml encoder. +// SetCBORMarshal sets the CBOR encoder. -// CBORUnmarshal returns xml unmarshal function in Core. +// CBORUnmarshal returns CBOR unmarshal function in Core. -// SetCBORUnmarshal Set xml decoder. +// SetCBORUnmarshal sets the CBOR decoder.
726-727: Consider enhancing Config struct for CBOR support.The current implementation allows setting CBOR functions but doesn't provide a way to specify CBOR as the preferred encoding in the Config struct. Consider:
- Adding a ContentType field to Config to allow specifying the encoding (JSON/XML/CBOR)
- Updating setConfigToRequest to handle CBOR encoding when specified
This would make CBOR support more accessible in the convenient request methods (Get, Post, etc.).
bind_test.go (1)
1102-1129: Consider using CBOR-specific struct tagsWhile the benchmark is well-implemented, consider using CBOR-specific struct tags for better clarity and to ensure CBOR-specific features can be utilized if needed in the future.
type Demo struct { - Name string `json:"name"` + Name string `cbor:"name" json:"name"` }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
go.modis excluded by!**/*.mod
📒 Files selected for processing (3)
bind_test.go(4 hunks)binder/cbor.go(1 hunks)client/client.go(4 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- binder/cbor.go
🔇 Additional comments (4)
client/client.go (2)
16-16: LGTM! Good choice of CBOR library and consistent field naming.
The fxamacker/cbor library is a solid choice as it's well-maintained, security-focused, and widely adopted. The new fields follow the established pattern used for JSON and XML.
Also applies to: 48-49
726-727: LGTM! Proper initialization of CBOR functions.
The CBOR marshal/unmarshal functions are correctly initialized in the New() constructor, following the same pattern as JSON and XML.
bind_test.go (2)
15-15: LGTM: Import of CBOR library
The chosen CBOR library (fxamacker/cbor) is a well-maintained and secure implementation.
931-936: LGTM: CBOR test case implementation
The test case properly validates CBOR encoding and decoding, following the same pattern as other encoding tests.
| cb, err := cbor.Marshal(&Request{ | ||
| BodyParam: "body_param", | ||
| }) | ||
| if err != nil { | ||
| t.Error(err) | ||
| } | ||
|
|
||
| testDecodeParser(MIMEApplicationJSON, `{"body_param":"body_param"}`) | ||
| testDecodeParser(MIMEApplicationXML, `<Demo><body_param>body_param</body_param></Demo>`) | ||
| testDecodeParser(MIMEApplicationCBOR, string(cb)) |
There was a problem hiding this comment.
Fix potential binary data corruption
Converting CBOR binary data to string and back could lead to data corruption. The testDecodeParser function should be used with the raw byte slice.
- testDecodeParser(MIMEApplicationCBOR, string(cb))
+ testDecodeParser(MIMEApplicationCBOR, cb)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| cb, err := cbor.Marshal(&Request{ | |
| BodyParam: "body_param", | |
| }) | |
| if err != nil { | |
| t.Error(err) | |
| } | |
| testDecodeParser(MIMEApplicationJSON, `{"body_param":"body_param"}`) | |
| testDecodeParser(MIMEApplicationXML, `<Demo><body_param>body_param</body_param></Demo>`) | |
| testDecodeParser(MIMEApplicationCBOR, string(cb)) | |
| cb, err := cbor.Marshal(&Request{ | |
| BodyParam: "body_param", | |
| }) | |
| if err != nil { | |
| t.Error(err) | |
| } | |
| testDecodeParser(MIMEApplicationJSON, `{"body_param":"body_param"}`) | |
| testDecodeParser(MIMEApplicationXML, `<Demo><body_param>body_param</body_param></Demo>`) | |
| testDecodeParser(MIMEApplicationCBOR, cb) |
| @@ -202,6 +203,33 @@ func Test_Client_Marshal(t *testing.T) { | |||
| require.Equal(t, errors.New("empty xml"), err) | |||
| }) | |||
|
|
|||
There was a problem hiding this comment.
This is missing a test using the default CBOR Marshall and UnMarshall functions as noted by codecov below.
| @@ -189,6 +192,12 @@ func parserRequestBody(c *Client, req *Request) error { | |||
| return err | |||
| } | |||
| req.RawRequest.SetBody(body) | |||
| case cborBody: | |||
| @@ -337,6 +338,12 @@ func (r *Request) SetXML(v any) *Request { | |||
| return r | |||
| } | |||
|
|
|||
| func (r *Request) SetCBOR(v any) *Request { | |||
| @@ -75,6 +75,11 @@ func (r *Response) JSON(v any) error { | |||
| return r.client.jsonUnmarshal(r.Body(), v) | |||
| } | |||
|
|
|||
| // CBOR method will unmarshal body to cbor. | |||
| func (r *Response) CBOR(v any) error { | |||
|
|
||
| type cborBinding struct{} | ||
|
|
||
| func (*cborBinding) Name() string { |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
ctx_test.go (1)
3661-3679: Consider enhancing custom encoder testThe custom encoder test is good but could be improved by:
- Testing error cases from the custom encoder
- Verifying the encoder is actually called with the expected input
- Testing with different CBOR data types
t.Run("custom cbor encoder error", func(t *testing.T) { app := New(Config{ CBOREncoder: func(_ any) ([]byte, error) { return nil, errors.New("custom error") }, }) c := app.AcquireCtx(&fasthttp.RequestCtx{}) err := c.CBOR(Map{"Name": "Test"}) require.Error(t, err) require.Equal(t, "custom error", err.Error()) })
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (6)
bind.go(2 hunks)client/client_test.go(2 hunks)ctx.go(1 hunks)ctx_interface_gen.go(1 hunks)ctx_test.go(2 hunks)docs/whats_new.md(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- ctx.go
- ctx_interface_gen.go
- docs/whats_new.md
🔇 Additional comments (7)
bind.go (2)
192-193: Implementation looks good, verify MIME type constant.
The CBOR case is correctly integrated into the content type switch statement.
Let's verify the MIME type constant is properly defined:
✅ Verification successful
MIME type constant is properly defined
The MIMEApplicationCBOR constant is correctly defined as "application/cbor" in constants.go, following the same pattern as other MIME type constants like MIMEApplicationJSON. The implementation is consistent and well-integrated.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify CBOR MIME type constant definition
# Check for MIMEApplicationCBOR constant
rg -l "MIMEApplicationCBOR.*=.*application/cbor" .
Length of output: 67
Script:
#!/bin/bash
# Let's verify the actual constant definition
rg "MIMEApplicationCBOR.*=.*application/cbor" -A 1 -B 1 ./constants.go
Length of output: 203
123-128: Implementation looks good, verify CBOR dependencies.
The CBOR method implementation follows the established pattern and correctly handles error cases and validation.
Let's verify the required CBOR dependencies are properly defined:
✅ Verification successful
CBOR dependencies are properly implemented
The verification shows that all required CBOR dependencies are correctly defined and implemented:
CBORBinderis defined inbinder/binder.goand implemented inbinder/cbor.goCBORDecoderis properly configured inapp.gowith a default implementation usingcbor.Unmarshalfromgit.luolix.top/fxamacker/cbor/v2- The implementation follows the same pattern as other encoders/decoders in the framework
- The CBOR content type is properly defined as a constant
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify CBOR binder and decoder implementations
# Check for CBORBinder definition
rg -l "var CBORBinder" binder/
# Check for CBORDecoder configuration
rg -l "CBORDecoder.*interface" config/
Length of output: 121
Script:
#!/bin/bash
# Let's try a broader search for CBOR-related code
echo "=== Searching for CBOR-related files ==="
fd -t f .
echo -e "\n=== Searching for CBOR-related code ==="
rg -i "cbor"
echo -e "\n=== Checking config package location ==="
fd -t f "config\.go"
echo -e "\n=== Checking binder package location ==="
fd -t f "binder\.go"
Length of output: 13617
client/client_test.go (3)
6-6: LGTM!
The addition of the encoding/hex import is necessary for CBOR test cases and follows Go's import grouping conventions.
206-231: Enhance test coverage with more complex CBOR test cases
The current test uses a simple CBOR value (null) and a generic error message. The test coverage should be expanded.
206-220:
Add test for default CBOR marshaling
The test suite is missing coverage for the default CBOR marshaling functionality. Add a test case that uses the default marshaling function instead of a custom one.
ctx_test.go (2)
3632-3649: LGTM! Well-structured CBOR encoding tests
The test cases effectively verify:
- Basic CBOR encoding functionality
- Content-type header setting
- Custom content-type support
- Hex encoding validation
3681-3702: LGTM! Well-implemented benchmark
The benchmark effectively tests CBOR encoding performance with:
- Realistic test data structure
- Proper memory allocation tracking
- Output validation
- Good use of require.NoError and require.Equal
| require.Error(t, c.CBOR(complex(1, 1))) | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
Enhance error handling test coverage
The error test for complex numbers is good, but should be expanded to cover more error cases:
- Test encoding of channels (should error)
- Test encoding of functions (should error)
- Test encoding of recursive structures (should error)
- Test encoding of very large numbers that may overflow
// Test invalid types
err = c.CBOR(make(chan int))
require.Error(t, err)
err = c.CBOR(func() {})
require.Error(t, err)
// Test recursive struct
type Recursive struct {
Next *Recursive
}
r := &Recursive{}
r.Next = r
err = c.CBOR(r)
require.Error(t, err)
Description
Adds support for CBOR encoding and decoding through Gofiber.
Fixes #3156
Type of change