-
Notifications
You must be signed in to change notification settings - Fork 8k
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
Gin Context implementation breaks context.Context contract #3888
Comments
I also encountered this confusion. I don’t know why gin does this. It seems to be a legacy issue. I can’t find a place to use it in the source code. Therefore I made changes in this PR(#3897) to be as compatible as possible. respect the context.WithValue contract well should better. |
A more compatible approach might be like this?
|
Fixed in #3897 Thanks @FarmerChillax |
Hi @appleboy , this feature is very important to me, I would like to know when it will be released |
Description
As also described in this issue, open-telemetry/opentelemetry-go-contrib#5277, the existing OpenTelemetry packages do not interact very well with gin.Context. It was pointed out here that this is an example of gin.Context not fulfilling the following specification of
context.Context.WithValue
:The provided key must be comparable and should not be of type string or any other built-in type to avoid collisions between packages using context. Users of WithValue should define their own types for keys.
The two pieces of code that are having colliding values in the context are here for OpenTelemetry, and here for Gin.
How to reproduce
Expectations
Actual result
Note that this is an issue as the span context will not be propagated properly unless a user passes c.Request.Context() explicitly. Since a gin.Context implements the context.Context interface, this is a subtle bug that would not be caught by the type system.
Environment
The text was updated successfully, but these errors were encountered: