-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Metadata context changes are not backwards compatible/break existing code #1219
Comments
I've put together two branches to make this more easily reproducible. Setup steps:
I pushed a branch To run:
Output:
I pushed another branch To run:
Output:
|
I think I have begun to identify the problem - if
Note the two In the old version pre-1.3.0, there are still two WithValue calls, but the metadata is copied to the second call, ie calling metadata.NewContext twice properly propagated the information:
Note this is printed from adding |
Well and there we go: it's because grpc-opentracing needs to be updated, so this was an in-memory issue: https://github.com/grpc-ecosystem/grpc-opentracing/blob/master/go/otgrpc/client.go#L53 grpc-ecosystem repos should be updated to reflect grpc-go changes, can we do this? This is going to be problematic (and why this breaking metadata change is really tough on consumers) because grpc-opentracing must update to the new metadata API, however this means that when users update grpc-opentracing, they must also update grpc-go (which may have other changes they do not want). grpc-opentracing does not have any releases/doesn't use semvar, so this is even tougher. I think as part of this, it would be great if we could get grpc-opentracing on semvar too? I hope this issue helps, let me know if there's anything I can do to assist. |
Thanks for the report and debugging info. This is definitely a problem, but I don't see any way this can be handled gracefully at this point. We are planning to remove the NewContext and FromContext functions from the metadata package completely in order to force users to decide which metadata they intended to set/get. Unfortunately, an API breakage is necessary here, because this is a security problem with the API itself. |
Yea I get it, just wanted to alert. Let me know if I can help in any way, I've tried to go through a few of the grpc-ecosystem repositories and send PRs. |
Note the example here is not just propagating contexts in memory, this is a full client/server interaction that should be serialized and work properly, ie this is not a dup of #1178. This should get into
transport/http2_client.go
andtransport/http2_server.go
, and work properly per the implementation in those files, we are not doing something likeFromContext(NewContext(ctx, md))
.I understand that the API was written so that existing users of
NewContext
andFromContext
would not be affected, but items are explicitly not being propagated now. See comment below to reproduce.I think this is a pretty serious bug. We're not doing anything THAT fancy with grpc-go, we effectively bring up a vanilla
grpc.Server
and install handlers on it, and then usegrpc.Invoke
with vanillagrpc.ClientConn
s. I don't think the implementation is working as intended - maybe I'm doing something wrong, but we are doing these calls across the wire and updating makes this break, I wanted to make sure everyone is alerted ASAP.The text was updated successfully, but these errors were encountered: