Repository navigation
Add messaging v1.43 shared contract - #19347
Merged
Merged
Conversation
Pull request dashboard statusMerged · refreshed 2026-08-03 18:29 UTC Status above doesn't look right?
|
Java resolves createForOperationType/builderForOperationType as plain create/builder overloads, because MessagingOperationType and MessageOperation erase to distinct parameter types. MessagingSpanNameExtractor already relies on this. Overloading gives the typed factories their final 3.0 names now, so the two "will be renamed in 3.0" markers can go away rather than needing a second audit pass after the 3.0 removals free up the names. This is source breaking but not binary breaking, and createForOperationType has no callers outside this repository. Also drop @nullable from the typed builder's operationType parameter. Its sibling create(getter, MessagingOperationType) was already non-null, and no caller passes null. The two tests that covered a null operation type with an explicit operation name now construct MessagingAttributesExtractorBuilder directly, which still accepts null for the legacy MessageOperation path. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 61998545-3856-4623-a7cb-4ebc5346c921
trask
force-pushed
the
trask/messaging-v1-43-contract
branch
from
July 31, 2026 16:36
72a0d43 to
d72fa4a
Compare
…ation name MessagingSpanNameExtractorBuilder only exposes setOperationName, which is a no-op on the legacy path, so builder(getter, MessageOperation) was equivalent to create(getter, operation). Inline the construction into create and drop the public overload. Reject setOperationName on legacy MessagingAttributesExtractorBuilder instances instead of silently ignoring it. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3db492fb-401c-4e9e-8fff-a7c9e89c5f3b
The boolean overload could not serve call sites that need a per-request decision, so it had no production callers. Replace it with a Predicate<REQUEST> so instrumentations that only sometimes propagate the send span context as the message creation context can use it. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: b190af98-6dd4-49f6-a62a-19abbbbab7a4
messaging.message.body.size and messaging.message.envelope.size are Opt-In in the v1.43 messaging semantic conventions, so they must not be emitted without explicit configuration. Keep emitting them on the old semconv path (including messaging/dup) to preserve existing behavior. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 5d6a6d06-2e10-41b5-8343-ad7dcb1a0dc8
This was referenced Aug 2, 2026
laurit
approved these changes
Aug 3, 2026
Contributor
There was a problem hiding this comment.
Pull request overview
Adds the shared API contract for opt-in v1.43 messaging semantic conventions while preserving legacy behavior for unmigrated instrumentations.
Changes:
- Adds operation types, span naming/kind extraction, attributes, and span keys for v1.43.
- Preserves v1.24 output through legacy overloads and stability selection.
- Adds coverage for legacy, stable, dual-emission, and bridge behavior.
Reviewed changes
Copilot reviewed 18 out of 18 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
AgentSpanTestingInstrumenter.java |
Includes create and settle span keys in bridge tests. |
ContextBridgeTest.java |
Verifies bridging of the new span keys. |
SpanKeyBridging.java |
Bridges new keys while supporting older application APIs. |
SemconvStabilityTest.java |
Tests messaging selection modes. |
SpanKey.java |
Defines create and settle context keys. |
SemconvStability.java |
Documents messaging stability accessors. |
MessagingSpanNameExtractorTest.java |
Tests legacy and v1.43 span names. |
MessagingSpanKindExtractorTest.java |
Tests operation-to-span-kind mapping. |
MessagingAttributesExtractorTest.java |
Tests attributes, errors, keys, and compatibility. |
MessagingSpanNameExtractorBuilder.java |
Adds configurable operation names. |
MessagingSpanNameExtractor.java |
Implements operation-first v1.43 naming. |
MessagingSpanKindExtractor.java |
Implements v1.43 span-kind selection. |
MessagingOperationType.java |
Defines v1.43 operation types. |
MessagingAttributesGetter.java |
Adds error-type extraction. |
MessagingAttributesExtractorBuilder.java |
Supports operation names and compatibility mode. |
MessagingAttributesExtractor.java |
Adds v1.43 and dual-emission attributes. |
MessageOperation.java |
Maps legacy operations to new operation types. |
build.gradle.kts |
Runs messaging tests in stable and dual modes. |
jaydeluca
approved these changes
Aug 3, 2026
This was referenced Aug 4, 2026
Closed
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
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.
Bottom of the stack that migrates messaging instrumentation to the v1.43 messaging semantic conventions. This layer adds the shared API the layers above build on; it touches no instrumentation module.
Background
We currently emit the v1.24 messaging conventions. #19254 has the research on why moving to the latest experimental conventions is safe for polyglot services. The new conventions are opt-in:
otel.semconv-stability.opt-inmessagingmessaging/dupThe top layer (#19357) additionally turns v1.43 on under the common v3 preview.
Because the migration is per-instrumentation, the shared API has to let migrated and unmigrated instrumentations coexist: opting in must not change what an instrumentation that has not migrated yet emits. That is what
supportsStableSemconvbelow is for.What's here
MessagingOperationType— the v1.43 operation types (create,send,receive,process,settle), replacingMessageOperation'spublish/receive/process.MessagingSpanKindExtractor— the v1.43 operation-to-span-kind model.receivebecomesCLIENT, andsendbecomesCLIENTrather thanPRODUCERwhen the span context is not propagated as the message creation context. Whether it is propagated can vary per request, so it is aPredicate<REQUEST>rather than a constructor-time flag.MessagingAttributesExtractor— emitsmessaging.operation.name,messaging.operation.type,messaging.client.id(renamed frommessaging.client_id) anderror.type, and reports a temporary destination's real name instead of the(temporary)placeholder.MessagingSpanNameExtractor— operation-first span names, preferring the destination template and omitting the destination for temporary and anonymous ones.SpanKeys for thecreateandsettleoperations.Each extractor is overloaded on
MessagingOperationType(new) andMessageOperation(legacy). An extractor built from a legacy overload carriessupportsStableSemconv = falseand keeps emitting only the old conventions no matter what the opt-in says, so an instrumentation that has not migrated is unaffected by a user opting in.Default-path impact
None. Everything new is behind
emitStableMessagingSemconv(), and unmigrated instrumentations are additionally pinned to the old conventions bysupportsStableSemconv.SemconvStability.emitStableMessagingSemconv()follows the naming pattern of its siblings; the messaging conventions it selects are still experimental.Part of #19254.