Summary
Bumping opentelemetry-semconv-incubating in hooks/open-telemetry from 1.28.0-alpha to 1.43.0-alpha renames the semantic convention attribute emitted by TracesHook:
- Old:
feature_flag.provider_name
- New:
feature_flag.provider.name
The FEATURE_FLAG_PROVIDER_NAME constant name is unchanged in the upstream library — only the string value it points to changes (underscore → dot). The hook code (OTelCommons.java) references the constant, not a literal, so no source change is needed there. Only hardcoded changes within TracesHookTest.java test file.
Why this is breaking
This is a silent, consumer-facing change: any existing dashboard, alert, or query in Datadog/Grafana/etc. built against the feature_flag.provider_name span attribute will stop matching once this ships, with no compile-time or runtime signal to the consumer.
hooks/open-telemetry is currently at 3.3.1 (1.0+), and per the org technical guidelines:
Efforts should be made to avoid breaking changes in 1.0+ artifacts... Please consult with a member of the TC before making breaking changes to a 1.0+ component.
Scope note
This issue/PR is scoped only to the pinned version bump and the one test-string fix. A separate follow-up PR will adopt newly-available semconv attributes (e.g. FEATURE_FLAG_RESULT_VARIANT) — intentionally not bundled here as more clarification and guidance is needed.
Ask
@beeme1mr @Kavindu-Dodan @thiyagu06 @toddbaert — as component owners for hooks/open-telemetry, could you direct/ share your thoughts on the changes I am proposing? This is actually my first time contributing so I want to make sure I follow best practices! Hope to hear from you all soon, thanks!
Summary
Bumping
opentelemetry-semconv-incubatinginhooks/open-telemetryfrom1.28.0-alphato1.43.0-alpharenames the semantic convention attribute emitted byTracesHook:feature_flag.provider_namefeature_flag.provider.nameThe
FEATURE_FLAG_PROVIDER_NAMEconstant name is unchanged in the upstream library — only the string value it points to changes (underscore → dot). The hook code (OTelCommons.java) references the constant, not a literal, so no source change is needed there. Only hardcoded changes withinTracesHookTest.javatest file.Why this is breaking
This is a silent, consumer-facing change: any existing dashboard, alert, or query in Datadog/Grafana/etc. built against the
feature_flag.provider_namespan attribute will stop matching once this ships, with no compile-time or runtime signal to the consumer.hooks/open-telemetryis currently at3.3.1(1.0+), and per the org technical guidelines:Scope note
This issue/PR is scoped only to the pinned version bump and the one test-string fix. A separate follow-up PR will adopt newly-available semconv attributes (e.g.
FEATURE_FLAG_RESULT_VARIANT) — intentionally not bundled here as more clarification and guidance is needed.Ask
@beeme1mr @Kavindu-Dodan @thiyagu06 @toddbaert — as component owners for
hooks/open-telemetry, could you direct/ share your thoughts on the changes I am proposing? This is actually my first time contributing so I want to make sure I follow best practices! Hope to hear from you all soon, thanks!