feat(otlp-exporter-base)!: allow passing an async function to headers option #5994
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Important
DRAFT - do not review, I'll be working through the issues listed below before taking it out of draft.
Which problem is this PR solving?
Implements dynamic headers for the HTTP-based exporters. The current internal implementation was already prepared for synchronous dynamic headers. A synchronous approach had two downsides that would've just limited its usefulness to end-users:
import
calls were impossible to use. Delaying the loading of any libraries so that the can be instrumented, was only possible in CJS, not ESM.To circumvent these issues, this PR makes the internal function used to obtain headers
async
and also allows the end-user to pass it to the exporter. There is still some potential of this feature being a footgun due to possible load-order issues, however, with the approach from this PR we can provide guidance on how to do this safely without causing issues. If needed, we can also provide a utility class to reduce friction later (see added documentation for an idea how that utility could look like).Other potential issues not tackled in this PR:
401
or403
so one HAS to do proactive token refresh.401
and403
be retryable. I've opted not to do this right now as I'd like to see if the current solution is "good enough"Closes #5756
Closes #2903