Add request id to logs.

[blkt]

Summary

This change adds a GRPC interceptor that fetches the header Grpc-Metadata-Request-Id and adds it to the logger. It also returns the request id to the client in the trailer, which is helpful for debugging.

CLI command minder history list was modified to show its usage, but those changes should be reverted.

Change Type

• Bug fix (resolves an issue without affecting existing features)
• Feature (adds new functionality without breaking changes)
• Breaking change (may impact existing functionalities or require documentation updates)
• Documentation (updates or additions to documentation)
• Refactoring or test improvements (no bug fixes or new functionality)

Testing

Manual tests.

Review Checklist:

• Reviewed my own code for quality and clarity.
• Added comments to complex or tricky code sections.
• Updated any affected documentation.
• Included tests that validate the fix or feature.
• Checked that related changes are merged.

[blkt]

This obviously needs to be reverted, but I'm wondering what would be the right way to output the request id in the CLI.

[coveralls]

coverage: 53.045% (-0.06%) from 53.105%
when pulling 4c55b9b on enh/request-id-interceptor
into 15fd53d on main.

[JAORMX]

in HTTP what would this translate to? I wonder how it works with the HTTP gateway we use.

[blkt]

GRPC moves back and forth headers having prefix Grpc-Metadata-, so it would become Grpc-Metadata-Request-Id.

[evankanderson]

We might want to use https://www.w3.org/TR/trace-context/ or https://uptrace.dev/opentelemetry/opentelemetry-traceparent.html

[blkt]

@evankanderson while estimating work to improve logging I had a look at the documents you linked. My take is that the capabilities described in those specs far exceed our current need, which is to track a request execution from start to finish in logs.

My take is that we're better off polishing this work, possibly changing the header's key (not the value), and merge it.

[evankanderson]

@evankanderson while estimating work to improve logging I had a look at the documents you linked. My take is that the capabilities described in those specs far exceed our current need, which is to track a request execution from start to finish in logs.

My take is that we're better off polishing this work, possibly changing the header's key (not the value), and merge it.

Sounds good; I'd thought this would be something like:

import "go.opentelemetry.io/otel/trace"

// ...
sc := trace.SpanContextFromContext(ctx)
ctx = zerolog.Ctx(ctx).With().Str("trace_id", sc.TraceID()).Logger().WithContext(ctx)

If there's a bunch more content, then I'd agree on doing our own thing.