🔥 feat: Add support for Express.js style req/res handlers #3809
Conversation
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. WalkthroughAdds adapters for Express-style, net/http, and fasthttp handler shapes to the request adapter, updates routing/docs to accept generic Changes
Sequence Diagram(s)sequenceDiagram
participant Router
participant Adapter as toFiberHandler
participant Wrapper as WrappedHandler
participant Ctx as fiber.Ctx
participant Express as ExpressHandler(Req,Res[,next])
Note right of Adapter #eef7ff: registration-time detection & wrapper creation
Router->>Adapter: register(handler:any)
Adapter->>Wrapper: return fiber.Handler wrapper(c)
Ctx->>Wrapper: incoming request -> wrapper(c)
Wrapper->>Express: call (req,res) or (req,res,next)
alt Express calls next()
Express->>Wrapper: next()
Wrapper->>Ctx: c.Next() (invoke downstream)
Ctx-->>Wrapper: downstream result
end
alt Express returns error
Express-->>Wrapper: returns error
Wrapper->>Ctx: propagate error (do not continue)
else Express returns nil
Express-->>Wrapper: returns nil
Wrapper->>Ctx: continue normal flow
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🧰 Additional context used📓 Path-based instructions (2)**/*.go📄 CodeRabbit inference engine (AGENTS.md)
Files:
**/*_test.go📄 CodeRabbit inference engine (AGENTS.md)
Files:
🧠 Learnings (7)📓 Common learnings📚 Learning: 2025-09-18T00:32:59.671ZApplied to files:
📚 Learning: 2025-10-16T07:19:52.418ZApplied to files:
📚 Learning: 2024-12-13T08:14:22.851ZApplied to files:
📚 Learning: 2024-10-02T23:03:31.727ZApplied to files:
📚 Learning: 2024-10-08T19:06:06.583ZApplied to files:
📚 Learning: 2025-10-16T07:15:26.529ZApplied to files:
🧬 Code graph analysis (1)adapter_test.go (3)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
🔇 Additional comments (7)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
gaby
changed the title
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3809 +/- ##
==========================================
- Coverage 92.07% 91.88% -0.20%
==========================================
Files 115 115
Lines 12249 12353 +104
==========================================
+ Hits 11278 11350 +72
- Misses 707 732 +25
- Partials 264 271 +7
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
/gemini review |
There was a problem hiding this comment.
Pull Request Overview
This PR adds support for Express.js style request/response handlers to Fiber's routing adapter, enabling developers to use familiar req/res callback patterns alongside Fiber's existing handler types.
- Added four new handler signatures:
func(Req, Res) error,func(Req, Res),func(Req, Res, func() error) error, andfunc(Req, Res, func() error) - Enhanced the routing adapter to automatically convert these Express-style handlers to native Fiber handlers
- Added comprehensive test coverage for all new handler signature variations
Reviewed Changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| adapter.go | Implements the core conversion logic for Express-style handlers in the toFiberHandler function |
| adapter_test.go | Adds comprehensive test coverage for all four new Express-style handler signatures |
| docs/whats_new.md | Documents the new Express-style handler support in the what's new section |
| docs/partials/routing/handler.md | Updates the routing documentation with Express-style handler examples |
| .github/README.md | Adds a dedicated section showcasing Express-style handler usage |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces excellent support for Express.js-style handlers, which will significantly improve interoperability and ease of migration for developers familiar with the Express ecosystem. The implementation is clean, the new handler signatures are well-covered by dedicated tests, and the documentation is clear and comprehensive. My main feedback is a minor improvement in the new tests to ensure they are robust against state leakage by using t.Cleanup for resource cleanup, which will prevent potential test flakiness.
There was a problem hiding this comment.
@gaby Should we also add an adaptor middleware for Express-style req/res handlers under middleware/adaptor/adaptor.go too? It isn't necessary to add it here, but we do have two versions of the net/http adapters.
Since we have adapter.go now, we could deprecate the middleware/adaptor in v3, and and keep all adapter-related code in adapter.go as an option for consistency.
On a side note, I also realized that the old handlers Handler signature still remained on a few doc pages as well:
- /docs/partials/routing/handler.md
- docs/api/app.md
|
@grivera64 Yeah the goal is to move some of the logic of adaptor to adapter, but wanted to get the structure first before making that change. The adaptor stills offers more support since it expects the fields. Will fix docs tonight. |
![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
🧹 Nitpick comments (4)
docs/partials/routing/handler.md (4)
30-36: Clarify the description of handler signatures and their capabilities.The description lists multiple handler types (Fiber, Express-style, net/http, and fasthttp), but the parenthetical explanation of Express-style handlers mixes the signature format with parameter descriptions in a way that may confuse readers about which parameters are required vs. optional.
Current:
func(fiber.Req, fiber.Res), with optionalfunc() errornextparameters and/orerrorreturn values`This could be interpreted as either "next is a parameter that's optional" or "the next parameter type is func() error and it's optional". Consider restructuring for clarity:
- Handlers can be native Fiber handlers (`func(fiber.Ctx) error`), Express-style - callbacks (`func(fiber.Req, fiber.Res)`, with optional `func() error` `next` - parameters and/or `error` return values), familiar `net/http` shapes such as + Handlers can be native Fiber handlers (`func(fiber.Ctx) error`), Express-style + callbacks with two, or three parameters and optional error returns (e.g., `func(fiber.Req, fiber.Res) error` or `func(fiber.Req, fiber.Res, next func() error) error`), familiar `net/http` shapes such as
38-43: Ensure the caution box context is clearly scoped to net/http handlers only.The caution block discusses net/http handlers being adapted through a compatibility layer. However, the statement "Because they cannot call
c.Next(), they will also terminate the handler chain" could be misread as also applying to Express-style handlers. Since Express-style handlers with anextcallback parameter CAN call the next handler, consider adding a clarifying sentence to scope the caution strictly to net/http::::caution Compatibility overhead - Adapted `net/http` handlers execute through a compatibility layer. They don't receive - `fiber.Ctx` or gain access to Fiber-specific APIs, and the conversion adds more - overhead than running a native `fiber.Handler`. Because they cannot call `c.Next()`, they will also terminate the handler chain. Prefer Fiber handlers when you need the - lowest latency or Fiber features. + Adapted `net/http` handlers execute through a compatibility layer and do not receive + `fiber.Ctx` or gain access to Fiber-specific APIs. The conversion adds overhead compared to native `fiber.Handler`. Note that plain `net/http` handlers cannot call `c.Next()` and will terminate the handler chain, whereas Express-style handlers with a `next` parameter can continue the chain. Prefer Fiber handlers when you need the + lowest latency or Fiber-specific features.
45-79: Example code demonstrates Express-style handlers well; verify completeness.The examples clearly show:
- Native Fiber handler (
func(fiber.Ctx) error)- Express-style with
nextcallback (func(req fiber.Req, res fiber.Res, next func() error) error)- Express-style without
next(func(req fiber.Req, res fiber.Res) error)- Plain net/http handler
- Fasthttp handler
The coverage is good, but Line 59 uses middleware scope (
app.Use) while Line 66 uses route scope (app.Get). Consider adding a brief comment noting that Express-style handlers work in both contexts to reinforce their flexibility:app.Get("/express", func(req fiber.Req, res fiber.Res) error { return res.SendString("Hello from Express-style handlers!") }) + + // Express-style handlers work in both middleware (Use) and route contexts
85-93: Verify Use method signatures reflect all supported parameter combinations.The updated
Usemethod signatures now use the genericanytype for handlers, which correctly enables Express-style handlers. The three overloads provided cover:
Use(handler any, handlers ...any)Use(path string, handler any, handlers ...any)Use(paths []string, handler any, handlers ...any)The signatures align with the PR objectives and enable flexible handler registration. However, consider adding a brief note that each handler parameter can independently be a Fiber handler, Express-style handler, net/http handler, or other supported type, to set expectations for mixing styles within a single call:
```go title="Signature" func (app *App) Use(args ...any) Router // Different usage variations func (app *App) Use(handler any, handlers ...any) Router func (app *App) Use(path string, handler any, handlers ...any) Router func (app *App) Use(paths []string, handler any, handlers ...any) Router func (app *App) Use(path string, app *App) Router + // Each handler can be a Fiber handler, Express-style handler, net/http handler, or other supported type
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
docs/api/app.md(2 hunks)docs/partials/routing/handler.md(3 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
docs/**
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Review and update the contents of the
docsfolder if necessary when modifying code
Files:
docs/api/app.mddocs/partials/routing/handler.md
🧠 Learnings (2)
📓 Common learnings
Learnt from: grivera64
PR: gofiber/fiber#3807
File: adapter_test.go:118-144
Timestamp: 2025-10-16T07:15:26.529Z
Learning: In Fiber v3, net/http handlers (http.Handler, http.HandlerFunc, or raw func(http.ResponseWriter, *http.Request)) can be passed directly to routing methods like app.Get(), app.Post(), etc. The framework automatically detects and wraps them internally via toFiberHandler/collectHandlers. The github.com/gofiber/fiber/v3/middleware/adaptor package is legacy and should not be suggested for tests or code using native net/http handler support.
📚 Learning: 2025-10-16T07:15:26.529Z
Learnt from: grivera64
PR: gofiber/fiber#3807
File: adapter_test.go:118-144
Timestamp: 2025-10-16T07:15:26.529Z
Learning: In Fiber v3, net/http handlers (http.Handler, http.HandlerFunc, or raw func(http.ResponseWriter, *http.Request)) can be passed directly to routing methods like app.Get(), app.Post(), etc. The framework automatically detects and wraps them internally via toFiberHandler/collectHandlers. The github.com/gofiber/fiber/v3/middleware/adaptor package is legacy and should not be suggested for tests or code using native net/http handler support.
Applied to files:
docs/partials/routing/handler.md
🪛 LanguageTool
docs/partials/routing/handler.md
[grammar] ~34-~34: There might be a mistake here.
Context: ...r` functions. Fiber automatically adapts supported handlers for you during regist...
(QB_NEW_EN)
[grammar] ~35-~35: There might be a mistake here.
Context: ...gistration, so you can mix and match the style that best fits your existing code....
(QB_NEW_EN)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
- GitHub Check: unit (1.25.x, windows-latest)
- GitHub Check: Compare
- GitHub Check: repeated
- GitHub Check: lint
🔇 Additional comments (2)
docs/api/app.md (2)
108-108: Group method signature correctly updated for Express-style handler support.The
Groupmethod signature now acceptshandlers ...any, enabling Express-style handlers to be passed as middleware for grouped routes. This aligns with the PR objectives and maintains API consistency with other routing methods.
156-167: Register interface signatures comprehensively updated to support multiple handler types.All methods in the
Registerinterface (All, Get, Head, Post, Put, Delete, Connect, Options, Trace, Patch, and Add) now accepthandler anyandhandlers ...anyparameters. This enables Express-style handlers across all HTTP methods and chainable route registration patterns.The signatures are consistent with the HTTP method routing functions shown earlier in the handler.md documentation and support the stated goal of allowing flexible handler adaptation.
|
@grivera64 Updated the docs and clarify some times based on CodeRabbit suggestions. |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
docs/partials/routing/handler.md (1)
61-72: Clarify the signature conventions for Express-style handlers in the examples.The examples show two different Express-style signatures:
- Three-parameter with
next:func(req fiber.Req, res fiber.Res, next func() error) error- Two-parameter without
next:func(req fiber.Req, res fiber.Res) errorThe documentation doesn't explicitly state that the
nextparameter is optional. Consider adding a brief inline comment or callout to clarify thatnextis optional and handlers can omit it entirely.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
docs/partials/routing/handler.md(3 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
docs/**
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Review and update the contents of the
docsfolder if necessary when modifying code
Files:
docs/partials/routing/handler.md
🧠 Learnings (2)
📓 Common learnings
Learnt from: grivera64
PR: gofiber/fiber#3807
File: adapter_test.go:118-144
Timestamp: 2025-10-16T07:15:26.529Z
Learning: In Fiber v3, net/http handlers (http.Handler, http.HandlerFunc, or raw func(http.ResponseWriter, *http.Request)) can be passed directly to routing methods like app.Get(), app.Post(), etc. The framework automatically detects and wraps them internally via toFiberHandler/collectHandlers. The github.com/gofiber/fiber/v3/middleware/adaptor package is legacy and should not be suggested for tests or code using native net/http handler support.
📚 Learning: 2025-10-16T07:15:26.529Z
Learnt from: grivera64
PR: gofiber/fiber#3807
File: adapter_test.go:118-144
Timestamp: 2025-10-16T07:15:26.529Z
Learning: In Fiber v3, net/http handlers (http.Handler, http.HandlerFunc, or raw func(http.ResponseWriter, *http.Request)) can be passed directly to routing methods like app.Get(), app.Post(), etc. The framework automatically detects and wraps them internally via toFiberHandler/collectHandlers. The github.com/gofiber/fiber/v3/middleware/adaptor package is legacy and should not be suggested for tests or code using native net/http handler support.
Applied to files:
docs/partials/routing/handler.md
🪛 LanguageTool
docs/partials/routing/handler.md
[grammar] ~34-~34: There might be a mistake here.
Context: ...r` functions. Fiber automatically adapts supported handlers for you during regist...
(QB_NEW_EN)
[grammar] ~35-~35: There might be a mistake here.
Context: ...gistration, so you can mix and match the style that best fits your existing code....
(QB_NEW_EN)
[grammar] ~44-~44: There might be a mistake here.
Context: ... Fiber handlers when you need the lowest latency or Fiber features. ::: ```go ti...
(QB_NEW_EN)
[grammar] ~45-~45: There might be a mistake here.
Context: ...ed the lowest latency or Fiber features. ::: ```go title="Examples" // Simple GE...
(QB_NEW_EN)
[grammar] ~99-~99: There might be a mistake here.
Context: ...tly be a Fiber handler, an Express-style callback, a net/http handler, or any o...
(QB_NEW_EN)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Compare
- GitHub Check: unit (1.25.x, windows-latest)
- GitHub Check: repeated
🔇 Additional comments (3)
docs/partials/routing/handler.md (3)
38-46: Verify the behavior claim that Express-style handlers with next don't terminate the chain.Line 43–45 states: "Express-style handlers are not subject to this limitation when they accept a
next func() errorparameter." This implies that Express-style handlers with anextparameter can continue the handler chain, whereasnet/httphandlers cannot. Confirm that this behavior is actually implemented and that callingnext()in an Express-style handler properly resumes the chain instead of terminating it.
30-36: Express-style handler documentation is clear and comprehensive.The updated paragraph clearly describes the four supported handler types (Fiber, Express-style, net/http, and fasthttp), explains that Fiber adapts them automatically, and invites mixing styles. The added details about Express-style signatures (optional
nextanderrorreturns) align well with the PR objectives.
30-46: Express-style handler methods verified and are correctly documented.Verification confirms that
fiber.Req.IP(),fiber.Res.SendStatus(), andfiber.Res.SendString()are all present in the interfaces with correct signatures (IP() string,SendStatus(status int) error,SendString(body string) error). The documentation accurately reflects the available API for Express-style handlers.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
docs/whats_new.md (3)
303-307: Clarify adapter vs adaptor terminology for consistency.The document uses both "adapter" (line 303, routing) and "Adaptor" (line 1130, middleware). While these reference different components, the mixed terminology may confuse readers. Consider either:
- Consistently using "adapter" throughout for both, or
- Clearly distinguishing "routing adapter" vs "adaptor middleware" on first mention in each section.
Based on static analysis hint about EN_WORD_COHERENCY.
318-323: Clarify error middleware behavior and next callback semantics.Cases 9–14 (error middleware) and the difference between
func() errorvsfunc()next callbacks (cases 5–8) lack explanation. For readers unfamiliar with Express error handling, clarify:
- When should error middleware (cases 9–14) be used vs regular middleware?
- How does the error parameter flow through the handler?
- What is the behavioral difference between error-returning and non-error-returning
nextcallbacks?Consider adding a brief note or grouping these cases into subsections with explanations.
305-307: Add detail on next callback error propagation.The explanation states Fiber wires
nexttoc.Next()for expected middleware behavior, but doesn't explain error propagation semantics. Consider adding:
- Whether errors returned from
next()are propagated to the handler's error return value, or handled separately- Why both
func() errorandfunc()next variants exist (when to use each)This would help developers understand cases 5–8 and 9–14 error-handling behavior more clearly.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.github/README.md(1 hunks)docs/whats_new.md(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- .github/README.md
🧰 Additional context used
📓 Path-based instructions (1)
docs/**
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Review and update the contents of the
docsfolder if necessary when modifying code
Files:
docs/whats_new.md
🧠 Learnings (2)
📓 Common learnings
Learnt from: grivera64
PR: gofiber/fiber#3807
File: adapter_test.go:118-144
Timestamp: 2025-10-16T07:15:26.529Z
Learning: In Fiber v3, net/http handlers (http.Handler, http.HandlerFunc, or raw func(http.ResponseWriter, *http.Request)) can be passed directly to routing methods like app.Get(), app.Post(), etc. The framework automatically detects and wraps them internally via toFiberHandler/collectHandlers. The github.com/gofiber/fiber/v3/middleware/adaptor package is legacy and should not be suggested for tests or code using native net/http handler support.
📚 Learning: 2025-10-16T07:15:26.529Z
Learnt from: grivera64
PR: gofiber/fiber#3807
File: adapter_test.go:118-144
Timestamp: 2025-10-16T07:15:26.529Z
Learning: In Fiber v3, net/http handlers (http.Handler, http.HandlerFunc, or raw func(http.ResponseWriter, *http.Request)) can be passed directly to routing methods like app.Get(), app.Post(), etc. The framework automatically detects and wraps them internally via toFiberHandler/collectHandlers. The github.com/gofiber/fiber/v3/middleware/adaptor package is legacy and should not be suggested for tests or code using native net/http handler support.
Applied to files:
docs/whats_new.md
🪛 LanguageTool
docs/whats_new.md
[uncategorized] ~306-~306: Do not mix variants of the same word (‘adapter’ and ‘adaptor’) within a single text.
Context: ... and fiber.Res helper interfaces. The adapter understands both two-argument (`func(fi...
(EN_WORD_COHERENCY)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
- GitHub Check: repeated
- GitHub Check: unit (1.25.x, macos-latest)
- GitHub Check: unit (1.25.x, windows-latest)
- GitHub Check: Compare
- GitHub Check: lint
|
/gemini review |
|
@codex review |
There was a problem hiding this comment.
Code Review
This pull request introduces excellent support for Express.js-style handlers, which will significantly improve the experience for developers migrating from Node.js. The implementation in adapter.go is comprehensive, and the tests are thorough. The documentation updates are also very detailed and helpful. I have a couple of suggestions to enhance maintainability and clarity.
.github/README.md
Outdated
| app.Use(func(err error, req fiber.Req, res fiber.Res, next func() error) error { | ||
| if err != nil { | ||
| return res.Status(fiber.StatusInternalServerError).SendString(err.Error()) | ||
| } | ||
| return next() | ||
| }) |
There was a problem hiding this comment.
This example for an error-handling middleware is a bit confusing. The if err != nil check is redundant because error-handling middleware is only invoked when an error has occurred, so err will never be nil. This also makes the return next() statement unreachable.
Here is a clearer example that demonstrates handling the error:
| app.Use(func(err error, req fiber.Req, res fiber.Res, next func() error) error { | |
| if err != nil { | |
| return res.Status(fiber.StatusInternalServerError).SendString(err.Error()) | |
| } | |
| return next() | |
| }) | |
| app.Use(func(err error, req fiber.Req, res fiber.Res, next func() error) error { | |
| // err is guaranteed to be non-nil. | |
| // You can handle the error and send a response. | |
| return res.Status(fiber.StatusInternalServerError).SendString(err.Error()) | |
| // To propagate the error instead, you would `return next()`. | |
| }) |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
.github/README.md(1 hunks)adapter.go(2 hunks)adapter_test.go(7 hunks)docs/partials/routing/handler.md(3 hunks)docs/whats_new.md(1 hunks)
🧰 Additional context used
📓 Path-based instructions (3)
**/*.go
📄 CodeRabbit inference engine (AGENTS.md)
**/*.go: Format Go code using gofumpt (Make target:make format).
Run golangci-lint for linting (Make target:make lint).
Rungo vetas part of audit to catch suspicious constructs (Make target:make audit).
Optimize struct field alignment with betteralign (Make target:make betteralign).
Applygopls modernizeto update code patterns (Make target:make modernize).
Files:
adapter.goadapter_test.go
**/*_test.go
📄 CodeRabbit inference engine (AGENTS.md)
**/*_test.go: Run the test suite with gotestsum (Make target:make test).
Run benchmarks withgo test(Make target:make benchmark).
Files:
adapter_test.go
docs/**
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Review and update the contents of the
docsfolder if necessary when modifying code
Files:
docs/partials/routing/handler.mddocs/whats_new.md
🧠 Learnings (8)
📚 Learning: 2025-10-16T07:15:26.529Z
Learnt from: grivera64
PR: gofiber/fiber#3807
File: adapter_test.go:118-144
Timestamp: 2025-10-16T07:15:26.529Z
Learning: In Fiber v3, net/http handlers (http.Handler, http.HandlerFunc, or raw func(http.ResponseWriter, *http.Request)) can be passed directly to routing methods like app.Get(), app.Post(), etc. The framework automatically detects and wraps them internally via toFiberHandler/collectHandlers. The github.com/gofiber/fiber/v3/middleware/adaptor package is legacy and should not be suggested for tests or code using native net/http handler support.
Applied to files:
adapter.goadapter_test.godocs/partials/routing/handler.md.github/README.mddocs/whats_new.md
📚 Learning: 2025-09-18T00:32:59.671Z
Learnt from: sixcolors
PR: gofiber/fiber#0
File: :0-0
Timestamp: 2025-09-18T00:32:59.671Z
Learning: In Go 1.22, manual copying of loop variables (like `x := x`) is no longer necessary due to the fix for variable capture in closures. Each loop iteration now creates its own instance of the loop variable automatically.
Applied to files:
adapter_test.go
📚 Learning: 2025-10-16T07:19:52.418Z
Learnt from: grivera64
PR: gofiber/fiber#3807
File: adapter_test.go:118-144
Timestamp: 2025-10-16T07:19:52.418Z
Learning: In the Fiber codebase, the linter does not allow `require` assertions from within HTTP handlers (including net/http-style handlers). Use `t.Fatalf`, `t.Errorf`, or similar `testing.T` methods for error handling inside handler functions instead.
Applied to files:
adapter_test.go
📚 Learning: 2024-12-13T08:14:22.851Z
Learnt from: efectn
PR: gofiber/fiber#3162
File: hooks_test.go:228-228
Timestamp: 2024-12-13T08:14:22.851Z
Learning: In Go test files, prefer using the `require` methods from the `testify` package for assertions instead of manual comparisons and calls to `t.Fatal` or `t.Fatalf`.
Applied to files:
adapter_test.go
📚 Learning: 2024-10-02T23:03:31.727Z
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/store.go:164-167
Timestamp: 2024-10-02T23:03:31.727Z
Learning: Unit tests in this project use testify require.
Applied to files:
adapter_test.go
📚 Learning: 2024-10-08T19:06:06.583Z
Learnt from: sixcolors
PR: gofiber/fiber#2922
File: middleware/cors/utils.go:63-71
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The project uses the testify/assert package for assertions in unit tests.
Applied to files:
adapter_test.go
📚 Learning: 2024-10-08T19:06:06.583Z
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:122-122
Timestamp: 2024-10-08T19:06:06.583Z
Learning: In `DefaultErrorHandler(c *fiber.Ctx, err error)`, since `c` is a pointer to an interface, we need to dereference `*c` when calling interface methods like `SendStatus`.
Applied to files:
docs/partials/routing/handler.md
📚 Learning: 2024-11-10T23:44:13.704Z
Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/adaptor/adaptor.go:111-111
Timestamp: 2024-11-10T23:44:13.704Z
Learning: In the `middleware/adaptor/adaptor.go` file of the Fiber framework, when updating context handling, replacing `c.Context()` with `c.RequestCtx()` is appropriate to access the `fasthttp.RequestCtx`.
Applied to files:
.github/README.md
🧬 Code graph analysis (2)
adapter.go (4)
app.go (1)
Handler(40-40)ctx_interface_gen.go (1)
Ctx(18-426)req_interface_gen.go (1)
Req(12-188)res_interface_gen.go (1)
Res(13-163)
adapter_test.go (3)
ctx_interface_gen.go (1)
Ctx(18-426)router.go (2)
App(366-385)Route(43-62)app.go (4)
App(68-110)New(515-628)Handler(40-40)Error(62-65)
🪛 LanguageTool
docs/partials/routing/handler.md
[style] ~30-~30: Consider using a more concise synonym.
Context: ...y) Router ``` Fiber's adapter converts a variety of handler shapes to native `func(fiber.Ct...
(A_VARIETY_OF)
.github/README.md
[uncategorized] ~198-~198: Do not mix variants of the same word (‘adapter’ and ‘adaptor’) within a single text.
Context: ...se mutations you performed. Because the adapter has to run the downstream stack once to...
(EN_WORD_COHERENCY)
docs/whats_new.md
[uncategorized] ~306-~306: Do not mix variants of the same word (‘adapter’ and ‘adaptor’) within a single text.
Context: ... and fiber.Res helper interfaces. The adapter understands both two-argument (`func(fi...
(EN_WORD_COHERENCY)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Compare
- GitHub Check: repeated
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
adapter.go (1)
350-357: Typed‑nil http.Handler is not detected (bug): reflect check never triggers
his an interface;reflect.ValueOf(h).Kind()isInterface, notPointer. The current check misses interface‑typed nil pointers, so a nil*MyHandlerstored inhttp.Handlerpasses through and can panic at runtime.Apply:
- hv := reflect.ValueOf(h) - if hv.Kind() == reflect.Pointer && hv.IsNil() { - return nil, false - } + hv := reflect.ValueOf(h) + // treat both interface-typed and pointer-typed nils as nil + if (hv.Kind() == reflect.Interface || hv.Kind() == reflect.Pointer) && hv.IsNil() { + return nil, false + }Add a test that passes a typed‑nil
http.Handler(e.g.,var h *struct{}cast tohttp.Handler) into the router and assertscollectHandlersrejects it.
🧹 Nitpick comments (3)
adapter.go (3)
106-120: Consolidate typed‑nil checks to reduce duplication and edge‑case riskMultiple adapters repeat
if h == niltyped‑nil checks. Centralize with a small helper (e.g.,isTypedNil(any) boolusing reflect for Func/Ptr/Interface) and remove per‑case boilerplate. This improves maintainability and makes future handler types safer.
392-402: WrapHTTPHandler: defensive nil handling is fine; add a quick-path for typed‑nilGiven the fix in
adaptHTTPHandler, this function is safe. Optionally early‑return on a typed‑nil interface with a small helper to match other adapters.
410-419: Handler index in panic is zero‑based; consider one‑based for UX
invalid handler #%duses zero‑basedi. Most users expect counting from 1.- panic(fmt.Sprintf("%s: invalid handler #%d (%T)\n", context, i, arg)) + panic(fmt.Sprintf("%s: invalid handler #%d (%T)\n", context, i+1, arg))
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
adapter.go(2 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.go
📄 CodeRabbit inference engine (AGENTS.md)
**/*.go: Format Go code using gofumpt (Make target:make format).
Run golangci-lint for linting (Make target:make lint).
Rungo vetas part of audit to catch suspicious constructs (Make target:make audit).
Optimize struct field alignment with betteralign (Make target:make betteralign).
Applygopls modernizeto update code patterns (Make target:make modernize).
Files:
adapter.go
🧠 Learnings (1)
📚 Learning: 2025-10-16T07:15:26.529Z
Learnt from: grivera64
PR: gofiber/fiber#3807
File: adapter_test.go:118-144
Timestamp: 2025-10-16T07:15:26.529Z
Learning: In Fiber v3, net/http handlers (http.Handler, http.HandlerFunc, or raw func(http.ResponseWriter, *http.Request)) can be passed directly to routing methods like app.Get(), app.Post(), etc. The framework automatically detects and wraps them internally via toFiberHandler/collectHandlers. The github.com/gofiber/fiber/v3/middleware/adaptor package is legacy and should not be suggested for tests or code using native net/http handler support.
Applied to files:
adapter.go
🧬 Code graph analysis (1)
adapter.go (2)
ctx_interface_gen.go (1)
Ctx(18-426)app.go (1)
Handler(40-40)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
- GitHub Check: unit (1.25.x, windows-latest)
- GitHub Check: lint
- GitHub Check: repeated
- GitHub Check: Compare
🔇 Additional comments (2)
adapter.go (2)
124-140: Wrap direct Fiber handlers to participate in express error resumeReturning
Handlerunchanged prevents skipping on resume and contributes to double execution downstream. Wrapping here (see diff in earlier comment) is necessary for correctness once express error adapters are in play.⛔ Skipped due to learnings
Learnt from: grivera64 PR: gofiber/fiber#3807 File: adapter_test.go:118-144 Timestamp: 2025-10-16T07:15:26.529Z Learning: In Fiber v3, net/http handlers (http.Handler, http.HandlerFunc, or raw func(http.ResponseWriter, *http.Request)) can be passed directly to routing methods like app.Get(), app.Post(), etc. The framework automatically detects and wraps them internally via toFiberHandler/collectHandlers. The github.com/gofiber/fiber/v3/middleware/adaptor package is legacy and should not be suggested for tests or code using native net/http handler support.
1-420: Code changes are well-tested; tooling verification required outside sandboxThe typed-nil handler checks and test coverage already exist in the code:
- Typed-nil detection for
http.Handleris implemented usingreflect.ValueOf()to check for pointer nil values (lines 351-354)- Test
TestCollectHandlers_TypedNilPointerHTTPHandlervalidates the typed-nilhttp.Handlerbehavior- Test
TestCollectHandlers_TypedNilFasthttpHandlerscovers fasthttp typed-nil cases- 36 comprehensive handler tests covering all branches (Fiber, Express, error handlers, nil cases)
However, the prescribed tooling passes (
make format,make lint,make audit,make betteralign,make modernize) cannot be verified in the sandbox environment due to missing build tools. The developer should confirm these passes locally before merging.
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
docs/whats_new.md (2)
581-599: Fix method signatures:DropandEndshould match usage.Examples use
return c.Drop()andreturn c.End(), so the signatures must returnerror.-```go -func (c Ctx) Drop() -``` +```go +func (c Ctx) Drop() error +``` -```go -func (c Ctx) End() -``` +```go +func (c Ctx) End() error +```Also applies to: 611-614
371-376: Invalid Go syntax inUseexample (array literal).Use Go slice literal syntax.
-// register multiple prefixes -app.Use(["/v1", "/v2"], func(c fiber.Ctx) error { +// register multiple prefixes +app.Use([]string{"/v1", "/v2"}, func(c fiber.Ctx) error {adapter.go (1)
131-135: Compile bug: usereflect.Ptr, notreflect.Pointer.
reflect.Pointeris not a valid Kind; the correct constant isreflect.Ptr.- if hv.Kind() == reflect.Pointer && hv.IsNil() { + if hv.Kind() == reflect.Ptr && hv.IsNil() { return nil, false }
♻️ Duplicate comments (1)
adapter_test.go (1)
41-44: Replace testify inside handler closures with testing.T (repo rule).Per project lint rules, avoid require/assert inside HTTP/Fiber/Express-style handler closures; use t.Fatalf/t.Errorf inside the closure or assert outside after invocation. Apply across the listed ranges.
Examples:
@@ - handler := func(c Ctx) { - require.Equal(t, app, c.App()) - c.Set("X-Handler", "ok") - } + handler := func(c Ctx) { + if c.App() != app { + t.Fatalf("c.App() mismatch") + } + c.Set("X-Handler", "ok") + }@@ - handler := func(req Req, res Res) { - assert.Equal(t, app, req.App()) - require.NoError(t, res.SendStatus(http.StatusCreated)) - } + handler := func(req Req, res Res) { + if req.App() != app { + t.Fatalf("req.App() mismatch") + } + if err := res.SendStatus(http.StatusCreated); err != nil { + t.Fatalf("SendStatus: %v", err) + } + }Repeat the same pattern for the other ranges (switch assert/require to t.Fatalf / capture state and assert outside). Based on learnings.
Also applies to: 75-79, 93-96, 110-114, 144-149, 175-179, 210-214, 244-248, 282-287
🧹 Nitpick comments (2)
docs/whats_new.md (1)
306-306: Consistency: “adapter” vs “Adaptor”.If “Adaptor” refers to the legacy middleware package and “adapter” to the routing adapter, consider adding a short note clarifying the distinction to avoid confusion.
adapter.go (1)
12-30: De-duplicate typed-nil checks at the top oftoFiberHandler.Centralize detection for typed-nil funcs/pointers/interfaces; simplifies adapters and reduces footguns.
func toFiberHandler(handler any) (Handler, bool) { if handler == nil { return nil, false } + // Unified typed-nil check (func/ptr/chan/map/slice/interface) + v := reflect.ValueOf(handler) + switch v.Kind() { + case reflect.Func, reflect.Ptr, reflect.Chan, reflect.Map, reflect.Slice, reflect.Interface: + if v.IsNil() { + return nil, false + } + } + switch handler.(type) {Then you can drop most per-case
if h == nil { return nil, false }checks.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
.github/README.md(1 hunks)adapter.go(2 hunks)adapter_test.go(7 hunks)docs/partials/routing/handler.md(3 hunks)docs/whats_new.md(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- .github/README.md
🧰 Additional context used
📓 Path-based instructions (3)
**/*.go
📄 CodeRabbit inference engine (AGENTS.md)
**/*.go: Format Go code using gofumpt (Make target:make format).
Run golangci-lint for linting (Make target:make lint).
Rungo vetas part of audit to catch suspicious constructs (Make target:make audit).
Optimize struct field alignment with betteralign (Make target:make betteralign).
Applygopls modernizeto update code patterns (Make target:make modernize).
Files:
adapter.goadapter_test.go
docs/**
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Review and update the contents of the
docsfolder if necessary when modifying code
Files:
docs/partials/routing/handler.mddocs/whats_new.md
**/*_test.go
📄 CodeRabbit inference engine (AGENTS.md)
**/*_test.go: Run the test suite with gotestsum (Make target:make test).
Run benchmarks withgo test(Make target:make benchmark).
Files:
adapter_test.go
🧠 Learnings (9)
📓 Common learnings
Learnt from: grivera64
PR: gofiber/fiber#3807
File: adapter_test.go:118-144
Timestamp: 2025-10-16T07:15:26.529Z
Learning: In Fiber v3, net/http handlers (http.Handler, http.HandlerFunc, or raw func(http.ResponseWriter, *http.Request)) can be passed directly to routing methods like app.Get(), app.Post(), etc. The framework automatically detects and wraps them internally via toFiberHandler/collectHandlers. The github.com/gofiber/fiber/v3/middleware/adaptor package is legacy and should not be suggested for tests or code using native net/http handler support.
📚 Learning: 2025-10-16T07:15:26.529Z
Learnt from: grivera64
PR: gofiber/fiber#3807
File: adapter_test.go:118-144
Timestamp: 2025-10-16T07:15:26.529Z
Learning: In Fiber v3, net/http handlers (http.Handler, http.HandlerFunc, or raw func(http.ResponseWriter, *http.Request)) can be passed directly to routing methods like app.Get(), app.Post(), etc. The framework automatically detects and wraps them internally via toFiberHandler/collectHandlers. The github.com/gofiber/fiber/v3/middleware/adaptor package is legacy and should not be suggested for tests or code using native net/http handler support.
Applied to files:
adapter.godocs/partials/routing/handler.mdadapter_test.godocs/whats_new.md
📚 Learning: 2024-10-08T19:06:06.583Z
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:122-122
Timestamp: 2024-10-08T19:06:06.583Z
Learning: In `DefaultErrorHandler(c *fiber.Ctx, err error)`, since `c` is a pointer to an interface, we need to dereference `*c` when calling interface methods like `SendStatus`.
Applied to files:
docs/partials/routing/handler.md
📚 Learning: 2025-09-18T00:32:59.671Z
Learnt from: sixcolors
PR: gofiber/fiber#0
File: :0-0
Timestamp: 2025-09-18T00:32:59.671Z
Learning: In Go 1.22, manual copying of loop variables (like `x := x`) is no longer necessary due to the fix for variable capture in closures. Each loop iteration now creates its own instance of the loop variable automatically.
Applied to files:
adapter_test.go
📚 Learning: 2025-10-16T07:19:52.418Z
Learnt from: grivera64
PR: gofiber/fiber#3807
File: adapter_test.go:118-144
Timestamp: 2025-10-16T07:19:52.418Z
Learning: In the Fiber codebase, the linter does not allow `require` assertions from within HTTP handlers (including net/http-style handlers). Use `t.Fatalf`, `t.Errorf`, or similar `testing.T` methods for error handling inside handler functions instead.
Applied to files:
adapter_test.go
📚 Learning: 2024-12-13T08:14:22.851Z
Learnt from: efectn
PR: gofiber/fiber#3162
File: hooks_test.go:228-228
Timestamp: 2024-12-13T08:14:22.851Z
Learning: In Go test files, prefer using the `require` methods from the `testify` package for assertions instead of manual comparisons and calls to `t.Fatal` or `t.Fatalf`.
Applied to files:
adapter_test.go
📚 Learning: 2024-10-02T23:03:31.727Z
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/store.go:164-167
Timestamp: 2024-10-02T23:03:31.727Z
Learning: Unit tests in this project use testify require.
Applied to files:
adapter_test.go
📚 Learning: 2024-10-08T19:06:06.583Z
Learnt from: sixcolors
PR: gofiber/fiber#2922
File: middleware/cors/utils.go:63-71
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The project uses the testify/assert package for assertions in unit tests.
Applied to files:
adapter_test.go
📚 Learning: 2024-12-15T19:56:45.935Z
Learnt from: ckoch786
PR: gofiber/fiber#3230
File: docs/whats_new.md:944-951
Timestamp: 2024-12-15T19:56:45.935Z
Learning: Detailed usage examples and explanations for new methods like `RemoveRoute` and `RemoveRouteByName` are documented in `docs/api/app.md`, so it's unnecessary to duplicate them in `docs/whats_new.md`.
Applied to files:
docs/whats_new.md
🧬 Code graph analysis (2)
adapter.go (4)
app.go (1)
Handler(40-40)ctx_interface_gen.go (1)
Ctx(18-426)req_interface_gen.go (1)
Req(12-188)res_interface_gen.go (1)
Res(13-163)
adapter_test.go (6)
ctx_interface_gen.go (1)
Ctx(18-426)app.go (3)
App(68-110)New(515-628)Handler(40-40)router.go (2)
App(366-385)Route(43-62)req_interface_gen.go (1)
Req(12-188)res_interface_gen.go (1)
Res(13-163)constants.go (4)
StatusCreated(53-53)StatusOK(52-52)MethodGet(5-5)StatusTeapot(91-91)
🪛 LanguageTool
docs/partials/routing/handler.md
[style] ~30-~30: Consider using a more concise synonym.
Context: ...y) Router ``` Fiber's adapter converts a variety of handler shapes to native `func(fiber.Ct...
(A_VARIETY_OF)
docs/whats_new.md
[uncategorized] ~306-~306: Do not mix variants of the same word (‘adapter’ and ‘adaptor’) within a single text.
Context: ... and fiber.Res helper interfaces. The adapter understands both two-argument (`func(fi...
(EN_WORD_COHERENCY)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (6)
- GitHub Check: Compare
- GitHub Check: lint
- GitHub Check: unit (1.25.x, macos-13)
- GitHub Check: repeated
- GitHub Check: unit (1.25.x, macos-latest)
- GitHub Check: unit (1.25.x, windows-latest)
🔇 Additional comments (2)
adapter_test.go (1)
129-133: Good use of t.Cleanup to avoid state leaks between tests.Resetting ctx.route and ctx.indexHandler via t.Cleanup ensures cleanup runs even on early failures.
Also applies to: 161-165, 195-199, 229-233, 262-266
docs/whats_new.md (1)
63-64: Go version requirement is accurate—no changes needed.The documentation correctly states the minimum supported version. The
go.modfile declaresgo 1.25.0on line 3, which aligns with the stated requirement that Fiber v3 drops support for Go versions below 1.25.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces support for Express.js style request/response handlers, which is a great feature for developers coming from Node.js backgrounds or those who prefer that style. The implementation is solid, with a clean refactoring of the handler adapter logic and comprehensive test coverage for all the new handler signatures. The documentation updates are also excellent, providing clear explanations and examples for the new feature across the README, routing guide, and what's new page. I have one minor suggestion to improve the performance note in the README to make it more comprehensive. Overall, this is a fantastic contribution to Fiber.
5 participants
Summary
Fixes #3806