@pjebs I kind of agree with this. We will discuss it internally.

@pjebs Although it is tempting to unify them, implementing the full context.Context interface on fiber.Ctx has subtle pitfalls:

• It would misrepresent or sabotage the built-in concurrency & lifecycles of Fiber’s context. Each fiber.Ctx only lives during the duration of the handler.
• It would likely break your code if you rely on “real” context cancellation across goroutines. This is because after the handler the fiber.Ctx is reset and store back in the pool for re-use.
• It introduces overhead that goes against Fiber’s zero-allocation, high-performance design. This is because we would have to create the context and channel for each fiber.Ctx.

• It would misrepresent or sabotage the built-in concurrency & lifecycles of Fiber’s context. Each fiber.Ctx only lives during the duration of the handler.

That's how any context should be in a Request-Response cycle.

• It would likely break your code if you rely on “real” context cancellation across goroutines. This is because after the handler the fiber.Ctx is reset and store back in the pool for re-use.

Currently that is already documented: https://docs.gofiber.io/#zero-allocation and already applies anyway with the current Ctx.

Because fiber is optimized for high-performance, values returned from fiber.Ctx are not immutable by default and will be re-used across requests. As a rule of thumb, you must only use context values within the handler, and you must not keep any references. As soon as you return from the handler, any values you have obtained from the context will be re-used in future requests and will change below your feet. Here is an example:

Currently if someone starts a goroutine that is expected to live longer than the request-response cycle, they are already expected to abide by the rules of using Fiber.

If they want to use a goroutine that outlives the Fiber request-response cycle, they should create a context.Context and pass that to the goroutine.

• It introduces overhead that goes against Fiber’s zero-allocation, high-performance design. This is because we would have to create the context and channel for each fiber.Ctx.

Yes this is true. But it can be created only once and never closed. It can be reused and documented what the rules are of using it.

Most likely, people will use it to store values anyway.
What is the purpose of anyway:

type fiber.Ctx interface {
	Context() context.Context       <============
	SetContext(ctx context.Context) <============

type context.Context interface {
	Deadline() (deadline time.Time, ok bool)
	Done() <-chan struct{}
	Err() error
	Value(key any)any
}

Here is an example of how to simply implement Deadline, Done and Err: https://www.youtube.com/watch?v=8M90t0KvEDY and https://www.youtube.com/watch?v=LSzR0VEraWw by @campoy who use to be in the Go Team: https://github.com/campoy/justforfunc/blob/master/10-contextimpl/context.go

Value can simply place values directly in to fasthttp's uservalues like Locals does right now.

@pjebs The fasthttp context already implements the functions from #3382

See:

• Deadline() https://github.com/valyala/fasthttp/blob/master/server.go#L2825
• Done() https://github.com/valyala/fasthttp/blob/master/server.go#L2835
• Err() https://github.com/valyala/fasthttp/blob/master/server.go#L2848
• Value() https://github.com/valyala/fasthttp/blob/master/server.go#L2863

Yes, but the aim is for fiber.Ctx to implement context.Context.
They recognised the importance of making fasthttp.RequestCtx implement it.
They just do a nop implementation for Deadline, Done and Err.
(Technically if the server shuts down, then they close the channel as a special case, but not if the client closes the connection which is what net/http does and is the ideal case - they believe it will effect performance).

Relevant valyala/fasthttp#1998