Logging interceptor does not correctly log client calls sent from a server about go-grpc-middleware

[jalaziz]

I'm happy to contribute a fix, but I'm not sure what the best solution is.

The simplest solution would be to override the fields in the context, but this would break the current API which allows you to manually override fields by setting them in the context before the logger is called.

Another solution could be to support multiple context markers, one for the default context and another for the user-provided context.

[johanbrandhorst]

@bwplotka refactored these for the v2 release, unfortunately I don't know what the best solution is here either.

[bwplotka]

Thanks for reporting--especially before 2.0!

This is indeed surprising and wrong. We have to establish a policy for inheriting & overriding the fields from context. Initially I thought it would be easier if those would be immutable, but for such cases it's clearly wrong idea as e.g. component is changing all the time depends where we log from. Flipped in #616

[jalaziz]

Thanks for reporting--especially before 2.0!

Just glad I caught it in our logs 🙏🏼 .

This is indeed surprising and wrong. We have to establish a policy for inheriting & overriding the fields from context. Initially I thought it would be easier if those would be immutable, but for such cases it's clearly wrong idea as e.g. component is changing all the time depends where we log from. Flipped in #616

The more I think about it, the more I agree that new should override old (that's generally what you'd expect from Context anyway). That being said, if support for overriding the fields is necessary, then I think the best option is to allow that to occur is via the WithFieldsFromContext option.