📝 [Proposal]: Revert of Reject Middleware context.Context PRs

[sixcolors]

Feature Proposal Description

We should Revert of Reject Middleware context.Context PRs.

Ref: #3339 #3340 #3364 #3365 #3175 #3287

If the goal is to make a service layer framework-agnostic, this approach does not achieve that.

These changes do not remove Fiber-specific dependencies—they add redundant storage without solving the actual issue. Instead of making middleware truly agnostic, they force extra overhead onto Fiber users and violate Fiber’s request-response model.

---

1. The Service Layer Still Needs Fiber-Specific Code

Even after these changes, the service layer still calls FromContext(), which now checks both fiber.Ctx and context.Context.

This means:

• The service layer remains aware of Fiber's middleware, contradicting the goal of true framework-agnostic design.
• Instead of cleanly separating concerns, this just adds another storage layer while keeping Fiber-specific logic.

🔹 A truly agnostic service layer would:
✅ Expect values only from context.Context, without needing Fiber-specific utilities.
✅ Require the caller to store values in context.Context before calling the service layer.

These PRs do not fix the real problem—they just make it more convoluted.

---

2. Unnecessary Redundancy for Fiber Users

For Fiber users who do not use context.Context, these changes introduce pointless duplication:

• Now, values are stored twice—once in Locals, once in context.Context.
• Extra allocations are performed on every request, increasing memory and CPU usage.
• Zero benefit for users who rely only on Fiber’s Locals.

Fiber’s Locals already provides efficient, request-scoped storage. If Fiber itself were designed around context.Context, this discussion would make sense—but that should be a framework-level decision, not a middleware-by-middleware patchwork.

🔴 The result?
❌ Unnecessary overhead for Fiber users.
❌ A second, redundant storage system that serves no real purpose.

---

3. This Is a Service Layer Problem, Not a Framework Problem

The root issue isn’t Fiber’s middleware—it’s how the service layer expects to retrieve values.

If a service layer is truly framework-agnostic, it should:
✅ Expect context.Context and rely on the caller to store values there before calling it.
✅ Avoid any framework-specific lookup functions.

Instead, these PRs try to bridge both worlds by keeping Fiber-specific lookups and adding a second storage mechanism, which helps neither case.

---

Conclusion: These PRs Should Be Reverted or Rejected

These PRs do not solve the problem—they just introduce inefficiency:

🛑 They fail to make the service layer framework-agnostic—Fiber-specific logic is still required.
🛑 They add redundant storage, increasing memory usage and allocations for no reason.
🛑 They break Fiber’s design principles by forcing a second, unnecessary request-scoped store.
🛑 If context.Context is truly needed, this should be addressed at the framework level, not middleware-by-middleware.

If we are serious about context.Context support in Fiber, we should focus on #3344 and consider a proper framework-level implementation, instead of merging piecemeal workarounds that introduce yet another redundant storage mechanism. As @pjebs said "Having too many different types of contexts is confusing".

Checklist:

• I agree to follow Fiber's Code of Conduct.
• I have searched for existing issues that describe my proposal before opening this one.
• I understand that a proposal that does not meet these guidelines may be closed without explanation.

[JIeJaitt]

@sixcolors I agree with you that these pr's don't exist to solve real problems, but simply to facilitate use and avoid writing a lot of repetitive and redundant code in the third point.

For example, I need to use requestID in the service layer, so if I have a hundred interfaces, I need to take the requestID out of the fiber and put it into the go native context every time in the controller layer.

Can we provide a new middleware that copies all the stored key-value pairs from fiber to go native context if the user wants? This would address the three points you raised.

what do you think？

[pjebs]

Why would the user want a native go context (eg. context.Background() => context.backgroundCtx) if fiber.Context implemented context.Context?

[sixcolors]

Why would the user want a native go context (eg. context.Background() => context.backgroundCtx) if fiber.Context implemented context.Context?

If i was unclear, I agree with your proposal as a possible solution. I think having multiple structs named context is confusing and unnecessary.

[pjebs]

My response was to jiejait

[sixcolors]

@sixcolors I agree with you that these pr's don't exist to solve real problems, but simply to facilitate use and avoid writing a lot of repetitive and redundant code in the third point.

For example, I need to use requestID in the service layer, so if I have a hundred interfaces, I need to take the requestID out of the fiber and put it into the go native context every time in the controller layer.

Can we provide a new middleware that copies all the stored key-value pairs from fiber to go native context if the user wants? This would address the three points you raised.

what do you think？

@JIeJaitt You can solve this issue easily in Fiber v3 with a custom middleware. Instead of modifying every core framework middleware to copy values into context.Context, you can create your own middleware that does this for you.

Example: Copy Fiber Middleware Values to context.Context

package main

import (
	"context"
	"log"

	"github.com/gofiber/fiber/v3"
	"github.com/gofiber/fiber/v3/middleware/requestid"
)

// In a real application, consider using an un-exported custom type for context keys
// to avoid collisions. However, if the service layer is in a separate package,
// this is not possible. In that case, the responsibility will have to be left
// to the developer to ensure no collisions occur.
const requestIDKey string = "request_id"

// Middleware to copy Fiber Middleware Values into Go context.Context
func WithFiberMiddlewareValuesToContext(c fiber.Ctx) error {
	ctx := c.Context()
	requestID := requestid.FromContext(ctx)
	if requestID != "" {
		ctx = context.WithValue(ctx, requestIDKey, requestID)
	}

	// Add other Fiber Middleware Values as needed
	// ...

	// Update the Fiber context with the new context
	c.SetContext(ctx)

	return c.Next()
}

// Example handler that uses the context
func Handler(c fiber.Ctx) error {
	userCtx := c.Context()
	requestID := ServiceLayer(userCtx)
	return c.SendString("Request ID: " + requestID)
}

// Example service layer function that uses the context.Context
func ServiceLayer(ctx context.Context) string {
	requestID, ok := ctx.Value(requestIDKey).(string)
	if !ok {
		return "Request ID not found"
	}
	return requestID
}

func main() {
	app := fiber.New()

	// Add request ID middleware
	app.Use(requestid.New())

	// Add other middleware as needed
	// app.Use(...)

	// Add custom middleware to copy Fiber Locals into Go context.Context for API group
	app.Use(WithFiberMiddlewareValuesToContext)

	// Example route
	app.Get("/", Handler)

	// Check for errors when starting the server
	if err := app.Listen(":3000"); err != nil {
		log.Fatalf("Failed to start server: %v", err)
	}
}

Why This Works Better?

✅ No need to modify Fiber’s core middleware
✅ No unnecessary overhead for Fiber users who don’t need context.Context
✅ Allows service layers to use context.Context if needed
✅ Keeps Fiber's request-response lifecycle intact

This approach avoids the redundancy of storing values in both Locals and context.Context across multiple middlewares, keeping the implementation simple and efficient.

[JIeJaitt]

Why would the user want a native go context (eg. context.Background() => context.backgroundCtx) if fiber.Context implemented context.Context?

Because the key-value pairs stored in Local are not stored in context.

[JIeJaitt]

@sixcolors I agree with you that these pr's don't exist to solve real problems, but simply to facilitate use and avoid writing a lot of repetitive and redundant code in the third point.
For example, I need to use requestID in the service layer, so if I have a hundred interfaces, I need to take the requestID out of the fiber and put it into the go native context every time in the controller layer.
Can we provide a new middleware that copies all the stored key-value pairs from fiber to go native context if the user wants? This would address the three points you raised.
what do you think？

@JIeJaitt You can solve this issue easily in Fiber v3 with a custom middleware. Instead of modifying every core framework middleware to copy values into context.Context, you can create your own middleware that does this for you.

Example: Copy Fiber Middleware Values to context.Context

package main

import (
"context"
"log"

"github.com/gofiber/fiber/v3"
"github.com/gofiber/fiber/v3/middleware/requestid"
)

// In a real application, consider using an un-exported custom type for context keys
// to avoid collisions. However, if the service layer is in a separate package,
// this is not possible. In that case, the responsibility will have to be left
// to the developer to ensure no collisions occur.
const requestIDKey string = "request_id"

// Middleware to copy Fiber Middleware Values into Go context.Context
func WithFiberMiddlewareValuesToContext(c fiber.Ctx) error {
ctx := c.Context()
requestID := requestid.FromContext(ctx)
if requestID != "" {
ctx = context.WithValue(ctx, requestIDKey, requestID)
}

// Add other Fiber Middleware Values as needed
// ...

// Update the Fiber context with the new context
c.SetContext(ctx)

return c.Next()
}

// Example handler that uses the context
func Handler(c fiber.Ctx) error {
userCtx := c.Context()
requestID := ServiceLayer(userCtx)
return c.SendString("Request ID: " + requestID)
}

// Example service layer function that uses the context.Context
func ServiceLayer(ctx context.Context) string {
requestID, ok := ctx.Value(requestIDKey).(string)
if !ok {
return "Request ID not found"
}
return requestID
}

func main() {
app := fiber.New()

// Add request ID middleware
app.Use(requestid.New())

// Add other middleware as needed
// app.Use(...)

// Add custom middleware to copy Fiber Locals into Go context.Context for API group
app.Use(WithFiberMiddlewareValuesToContext)

// Example route
app.Get("/", Handler)

// Check for errors when starting the server
if err := app.Listen(":3000"); err != nil {
log.Fatalf("Failed to start server: %v", err)
}
}

Why This Works Better?

✅ No need to modify Fiber’s core middleware ✅ No unnecessary overhead for Fiber users who don’t need context.Context ✅ Allows service layers to use context.Context if needed ✅ Keeps Fiber's request-response lifecycle intact

This approach avoids the redundancy of storing values in both Locals and context.Context across multiple middlewares, keeping the implementation simple and efficient.

I agree with this, but I wonder if a whole new middleware is provided, like the adaptor middleware, Converter for net/http handlers to/from Fiber request handlers.

This new middleware could copy all the key-value pairs stored in Local to the native Go context.

[sixcolors]

I agree with this, but I wonder if a whole new middleware is provided, like the adaptor middleware, Converter for net/http handlers to/from Fiber request handlers.

This new middleware could copy all the key-value pairs stored in Local to the native Go context.

Yes, copying Locals to a context.Context would be trivial to implement. However, best practice in Go is to use unexported keys when storing values in a context.

Since each Fiber middleware is its own package, users do not have access to the unexported keys needed to retrieve values from Locals. This is why each Fiber middleware provides FromLocal functions—to ensure collision-free access to stored values.

Given this, I still conclude that it's best left to the developer to implement based on their specific needs.