feat(config): propagator plugin loading via entry points for declarative config#5098
Open
MikeGoldsmith wants to merge 7 commits intoopen-telemetry:mainfrom
Open
Conversation
Extracts a generic `load_entry_point(group, name)` helper into `_common` so that resource detector, exporter, propagator, and sampler plugin loading in declarative file config can all use the same entry point lookup pattern rather than duplicating it. Refactors `_propagator.py` to use the new util, removing its inline entry point lookup. Assisted-by: Claude Sonnet 4.6
Assisted-by: Claude Sonnet 4.6
TextMapPropagator is changed from @DataClass to TypeAlias = dict[str, Any] in models.py, preserving unknown propagator names (plugin names) as dict keys through the config pipeline — same approach as Sampler. _propagators_from_textmap_config() now iterates the dict's key-value pairs directly. Known names (tracecontext, baggage) are bootstrapped from _PROPAGATOR_REGISTRY. All other names — including b3, b3multi, and custom plugin propagators — fall back to load_entry_point("opentelemetry_propagator", name), matching the spec's PluginComponentProvider mechanism. Assisted-by: Claude Sonnet 4.6
This was referenced Apr 20, 2026
Python dataclasses don't enforce types at runtime, so factory functions can accept raw dicts directly. This removes the need to change TextMapPropagator from a @DataClass to a TypeAlias. Assisted-by: Claude Opus 4.6 (1M context)
Use typed TextMapPropagatorConfig with additional_properties from the @_additional_properties decorator instead of raw dict iteration. Known propagators (tracecontext, baggage) are checked via typed fields and _PROPAGATOR_REGISTRY. Known schema fields not in the registry (b3, b3multi) and unknown plugin names from additional_properties are loaded via entry points. Assisted-by: Claude Opus 4.6
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Description
Extends propagator support in declarative file configuration to handle custom (plugin) propagators in the
compositelist, matching the spec's PluginComponentProvider mechanism.Depends on #5131 (
additional_propertiessupport for generated models).Solution
_propagators_from_textmap_config()uses typedTextMapPropagatorConfigfields andadditional_properties:tracecontext,baggage) are bootstrapped directly from the SDK via_PROPAGATOR_REGISTRYb3,b3multi) are loaded viaload_entry_point("opentelemetry_propagator", name)additional_propertiesare also loaded via entry pointsCustom propagator example
Closes #5070