Walkthrough

Widen middleware context accessors to accept a generic ctx any, and propagate middleware values into the standard Go context.Context via c.SetContext(context.WithValue(...)), enabling retrieval from fiber.Ctx, fiber.CustomCtx, *fasthttp.RequestCtx, or context.Context.

Changes

Sequence Diagram(s)

mermaid
sequenceDiagram
participant Client as Client
participant Fiber as Fiber App
participant MW as Middleware
participant Locals as Locals
participant GoCtx as Go Context
participant Handler as Downstream

Client->>Fiber: HTTP request
Fiber->>MW: enter middleware
MW->>Locals: set Locals(key)=value
MW->>GoCtx: c.SetContext(context.WithValue(...))
MW->>Handler: pass to next handler
Handler->>GoCtx: read via FromContext(ctx any)
Handler->>Locals: or read from Locals / RequestCtx

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

• 🔥 feat: Add Context Support to RequestID Middleware #3200 — Similar requestid middleware changes adding context propagation and broadened FromContext handling.
• 🐛 bug: Fix support for context.Context #3720 — Adds Ctx.SetContext() / Ctx.Context() APIs used for middleware → Go-context propagation.
• docs: note removal of context keys #3707 — Implements context-agnostic helper APIs across middleware (FromContext/TokenFromContext/UsernameFromContext).

Suggested reviewers

• sixcolors
• ReneWerner87
• efectn

Poem

🐰 I hopped from Locals into GoCtx bright,
I carried names and tokens through the night.
From Fiber, RequestCtx, or plain ctx any,
A little rabbit finds the value many.
Hooray — cross-context crumbs make me light!

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 @coderabbitai help to get the list of available commands and usage tips.}

Summary of Changes

Hello @gaby, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the robustness and interoperability of middleware context handling within the Fiber framework. By allowing middleware helpers to gracefully handle various context types and ensuring values are consistently stored across both Fiber's internal locals and Go's standard context, the changes improve API flexibility and compatibility with diverse Go programming patterns. This makes it easier for developers to integrate Fiber middleware with existing codebases that might use different context implementations.

Highlights

• Expanded Context Helper Compatibility: Middleware helper functions now accept a broader range of context types, including fiber.Ctx, *fasthttp.RequestCtx, and context.Context, preventing panics when an unexpected type is provided.
• Consistent Value Storage: Values set by middleware are now mirrored into both Fiber's local context (c.Locals) and Go's standard context.Context (c.SetContext(context.WithValue(c.Context(), key, val))), ensuring consistent lookups across different APIs and compatibility with plain context.Context or raw fasthttp contexts.
• Documentation and Test Updates: The official documentation for affected middleware has been updated to reflect the new any-typed helper signatures, and new tests have been added or adjusted to verify correct behavior across all three supported context types.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Note to myself: Add support for CustomCtx

Codecov Report

❌ Patch coverage is 97.82609% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 91.05%. Comparing base (562043e) to head (05d6ba8).
⚠️ Report is 34 commits behind head on main.

@@            Coverage Diff             @@
##             main    #4079      +/-   ##
==========================================
+ Coverage   90.99%   91.05%   +0.06%     
==========================================
  Files         119      119              
  Lines       11337    11337              
==========================================
+ Hits        10316    10323       +7     
+ Misses        648      643       -5     
+ Partials      373      371       -2     

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

Follow-up: All middleware keys are unexported - helpers required anyway

Just realized something important: all middleware use unexported context keys, which means external services can't access the values directly even if they're stored in context.Context.

// All these are unexported (lowercase or private types)
requestid:   requestIDKey contextKey = iota
session:     middlewareContextKey middlewareKey = iota  
basicauth:   usernameKey contextKey = iota
keyauth:     tokenKey contextKey = iota
csrf:        tokenKey contextKey = iota

So in an external service layer, this won't work:

// ❌ Can't access - key is unexported
ctx.Value(requestIDKey)  // Compile error - requestIDKey not accessible

External services must import the middleware package:

// ✅ Required approach
import "github.com/gofiber/fiber/v3/middleware/requestid"

rid := requestid.FromContext(ctx)  // Must use this helper

This means: Whether we store in context.Context eagerly or on-demand, external services need the same import and helper call. The only difference is whether we pay the performance cost on every request vs only when needed.

If we're already requiring import + FromContext(), why not let users opt into the allocation cost instead of forcing it on everyone?

Actually, thinking about this more - since the middleware keys are unexported anyway, why not just provide helper functions or example code that let users export values to their own context keys when needed?

We have to strike a balance between performance and user experience here.

In internal discussions, we have come to the conclusion
that we do not want to impose these extra allocations on all users who use the middleware, thereby directly reducing performance
since users should normally have direct access to fiber.CTX and be able to use it

However, there is still the option of combining everything under one implementation -> by only filling the user context if the fiber user explicitly requests it via the app config setting or mw setting
f.e.

app := fiber.New(fiber.Config{
   StoreDataInUserContext: true, // <- best name ever .... TBD :D, default "false"
})

or direct in the specific mw

app.Use(requestid.New(requestid.Config{
    ...
    StoreDataInUserContext: true // default "false"
})

This allows us to strike a balance between performance and convenience.

The problem with the key not being exported does not exist here either, as access is only via helper functions that know about the key because they are part of the middleware solution code.

@gaby @sixcolors
I think we can proceed with this, or are there still concerns that are not mentioned in the text?

@ReneWerner87 Yeah, that's my plan. I'm adding the config option at the app level because some of the middleware do not have a New, for example proxy. That way we don't limit ourselfs in the future.

I have these changes on my To-Do list for this weekend.

I'm thinking through the goal here and realize we might be missing the actual problem.

The goal as I understand it (#4066) is to enable services that aren't Fiber-aware to access middleware values. But this PR doesn't achieve that—it just stores unexported keys in multiple contexts instead of one. External services still can't call ctx.Value(requestIDKey) because the key isn't exported, so they still need to import "fiber/middleware/requestid" and call requestid.FromContext().

So we're not giving services any real independence from Fiber.

If we want truly Fiber-agnostic services, we'd need to either:

• Export the context keys (so services can access them directly, though it would still require a package import and is not Go best practice per context docs), or
• Document that users should map middleware values to their own context keys at the app level (which is a single line of code in the handler)

app.Get("/test", func(c *fiber.Ctx) error {
    id := requestid.FromContext(c)
    service(context.WithValue(c.Context(), myRequestIDKey, id)) // Manual bridge.
    return c.SendStatus(200)
})

if services need to be fiber aware I’m not sure why users wouldn’t just pass the fiber ctx.

Okay, the unexported keys are a problem if it has to be the case that the external tools are completely independent of the middleware itself and no helper can be used.
Do we know for sure that the user really doesn't want to use a helper?

Perhaps we need to clarify again exactly what needs to be achieved in order to be able to evaluate it again.
Maybe this manual bridge can also be simplified.

Or we could do something like this

app.Use(requestid.New(requestid.Config{
    ...
    StoreInUserContext: "keyName" // default "" - off 
})

But let's find out the parameter for this implementation