go-grpc-middleware
go-grpc-middleware copied to clipboard
grpc-ecosystem
v2 tags: Add tests and examples replacement for gogo.moretags
We are removing gogo support from v2. The reason is that gogo is no longer maintained as far as things are right now (Not a surprise: it's a huge backlog of work that overlaps with https://github.com/protocolbuffers/protobuf-go)
This means that we can't have tags interceptor test cases anymore as the things are now. We can still release tags as they were in middleware v1, but there are currently no tests or good example that works. (Let's discuss that in [the PR](https://github.com/grpc-ecosystem/go-grpc-middleware/pull/321 @johanbrandhorst @yashrsharma44)
The only question is what's next. https://github.com/protocolbuffers/protobuf-go is not adding such an option, so probably we can use any of community driven efforts like or ensure there is a standard way to enabling tag options somehow. There are a couple of options (See https://github.com/golang/protobuf/issues/52 for full discussion):
- https://github.com/searKing/golang/tree/master/tools/cmd/protoc-gen-go-tag
- https://github.com/favadi/protoc-go-inject-tag (that looks promising but options feels weird, added issue: https://github.com/favadi/protoc-go-inject-tag/issues/40)
- https://github.com/qianlnk/protobuf/tree/master/protoc-gen-go/retag
- probably more.. (:
Would be nice to decide on before adding tags back to v2. Does this plan make sense?
Help wanted to define what should we use 🤗
Personally I would vote in favour of not making an opinionated decision here and simply not supporting tags until APIv2 does (if ever). I see this project as lightweight and unopinionated, and we should avoid ambiguity where users may be forced to make a choice they don't want to.
On a personal note, I've never used tags, so I'm not sure they're that crucial either?
I believe tags are crucial to generate request/operation ID, no? Also we used tags to pass info between middlewares (across network even!). 🤔 We definitely did not use this feature of auto extraction of tags messages though.
I think we are missing good requirements spec (:
From my side, AC:
- grpc middlewares have a way to extract request/operation ID for logging and tracing purposes from outside (caller) or generate a new one that is missing.
- Passing info between middlewares / across middlewares across network is kind of critical for request ID passing as well.
If we simplify tags to just passing stuff no extraction from types - I think we could have them in v2 or after (:
In my experience you can defer "requestID" generation to your choice of trace provider, for example, opencensus makes that accessible in the context.
What about passing it through? Kind Regards, Bartek Płotka (@bwplotka)
On Mon, 18 Jan 2021 at 19:52, Johan Brandhorst-Satzkorn < [email protected]> wrote:
In my experience you can defer "requestID" generation to your choice of trace provider, for example, opencensus makes that accessible in the context.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/grpc-ecosystem/go-grpc-middleware/issues/382#issuecomment-762443057, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVA3O2QWT7WX5Z4JBG7PDTS2SGOFANCNFSM4WFQNKWA .
That's the point of tracing, it lives in your context, and is automatically transferred across network boundaries by your trace provider (like ocgrpc).
As talked offline, agree. Removing field extraction.
Still torn on tags passing between middleware that only works if Tags interceptor is enabled. It's super confusing. I think I will kill whole interceptor/tag package for v2. We can leave the context passed tags so user can put there tags that can be used for tracing, and logging 🤔 But it will always work - no special tags interceptor needed. It will be clearer when I will propose something in a PR.
I can see there are literally two context states:
niceMD and tags
niceMd are metadata trailers (type MD map[string][]string) passed between gRPC peers, tags are internal (map[string]string)
I think it's a good moment to rethink this, unified this and put them in single/separate focused packages that will allow to understand them better.... vs just utils package =D
I feel all of this should be part of tracing... But then it makes logging weird as it would use tracing parts 🤔
A logger can extract span and trace IDs from the context so that tags attached to a trace can be mapped to a log message by including the trace ID in any log messages.
It can yes... but not sure what we want to have on our middleware then. Kind of sucks to reimplement context logger
Tags are removed. gogo.moretags are not supported. Will mention in "migration guide" which is being produced here https://github.com/grpc-ecosystem/go-grpc-middleware/pull/543