We have observed that there is support for propagating the request ID through the standard context.Context, like the zerolog library supports it.
We think that the support for such propagation is not working as expected, since it breaks the expectation of a plain zerolog user of having a zerolog logger instance on the context, since the lecho.Logger is saved inside the middleware.
As a consequence client code calling zerolog.Logger.log.Ctx(ctx) will not receive a logger and no log events will be generated.
Imagine an example codebase having API and a servicer struct. Somewhere in the API handler you have
Hi,
Thanks for maintaining this library.
We have observed that there is support for propagating the request ID through the standard
context.Context
, like the zerolog library supports it.We think that the support for such propagation is not working as expected, since it breaks the expectation of a plain zerolog user of having a zerolog logger instance on the context, since the lecho.Logger is saved inside the middleware. As a consequence client code calling zerolog.Logger.log.Ctx(ctx) will not receive a logger and no log events will be generated.
Imagine an example codebase having API and a servicer struct. Somewhere in the API handler you have
In FooServicer:
Expectation is that the log line above produces a log event, optionally with a requestId present (should the request ID middleware be mounted).
Actually, nothing happens for the reasons described above.
This PR fixes this scenario.