@zanvd how about we use context.WithoutCancel(ctx) here? This way the cancellation won't be propagated while the values stored in the context can be. Would that also solve the root issue? 🤔

context.WithoutCancel was a great addition to context lately, but here if we use it, it means the context stored again won't be canceled if orgCtx is canceled. It doesn't a good move

Ah, you're right.

My point is that restoring the context will also remove all context values. If someone uses middleware that uses the context after the handler is executed, it will be lost this way.

Here is the way then

orgCtx := msg.Context() 
ctx, cancel := context.WithTimeout(orgCtx, timeout)

defer func() {
   cancel()
   ctx, cancel2 := context.WithCancelWithCause(context.WithoutCancel(ctx))
   msg.SetContext(ctx)
   go func() {
        <- ctx.Done()
        cancel2(ctx.Err())
   }
}()

But I find it ugly

I'd have to test it out, but this is more or less why I was asking on Discord about usage of context within Message - makes it sort of a global object that anyone can modify. Since the blueprint for this was the net/http package, I'd follow its logic and not even allow changing of the Message's context. Not something to solve in this PR, though.

What would be an example of values stored in the context that we should be vary of? Perhaps copying them to the original context might be a temporary solution.