-
-
Notifications
You must be signed in to change notification settings - Fork 202
huma.WithContext() destroys original humago Context #784
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I also tried replacing: ridCtx := context.WithValue(ctx.Context(), key{}, "value")
ctx = huma.WithContext(ctx, ridCtx) with:
but still got the same panic. |
This seems to work: func WithContext(ctx huma.Context, reqCtx context.Context) huma.Context {
req, resp := humago.Unwrap(ctx)
req = req.WithContext(reqCtx)
ctx = humago.NewContext(ctx.Operation(), req, resp)
return ctx
} Usage: func(ctx huma.Context) {
...
ctx = WithContext(ctx, context.WithValue(ctx.Context(), key{}, "value"))
} It'd be great if |
The workaround in the previous comment seems to break testing using the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm using humago.
I have a chain of middleware, and one of the later ones needs to use
humago.Unwrap()
to access the underlyinghttp.Request
to log some attributes that are not available inhuma.Context
(e.g.useragent
).One of the earlier middleware is injecting a key into the request context (
context.Context
), which naturally creates a new context. The new context is then reattached to the huma context usinghuma.WithContext()
.However, after that point,
humago.Unwrap(ctx)
panics with the error:not a humago context
.If I move the panicking middleware up the chain so that it runs before the middleware that modifies the context, it works fine.
Here is a minimal example to reproduce the problem (
TestMiddleware
is the one that panics):The text was updated successfully, but these errors were encountered: