Configurable client identification headers and/or base Otel attributes

[wainglaister]

Component(s)

router

Is your feature request related to a problem? Please describe.

I'm looking at a migration to using router and I have a number of currently used custom headers to deal with, this includes client name, version and referrer.

Describe the solution you'd like

Initially I was thinking that the config.yaml could include settings for custom header keys which would override the defaults, but that would only solve part of the problem (it could well cater for a good % of people).

Ideally the custom module needs access to more of the lifecycle, NewClientInfoFromRequest is called before Middleware so the request can't be updated (which would be a hack anyway). Really access is required to baseAttributeValues so that arbitrary details can be added to all spans (the module should have access to all steps that create a span...).

Describe alternatives you've considered

Using a custom module to store the custom headers and inject them on the available spans for each request (covers only a small subset of the spans).

There are a lot of interfaces used in the codebase, but almost no way to supply an implementation to be used (that I'm aware of) (nice and general, high effort).

Add custom module callbacks for any stage where a span is created (not all in the router so not so easy.

Additional context

Thinking to the future I'm interested in how this all applies to subscriptions / web sockets

[github-actions]

WunderGraph commits fully to Open Source and we want to make sure that we can help you as fast as possible.
The roadmap is driven by our customers and we have to prioritize issues that are important to them.
You can influence the priority by becoming a customer. Please contact us here.

[jensneuse]

We need this for a customer and are looking at implementing it in a configurable way. Currently, we don't have a specific timeline.