Skip to content

Select schema URLs from the primary semantic-convention domain #20755

Closed

Description

@trask

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

InstrumenterBuilder previously inferred a schema URL from attribute extractors. A supporting extractor could determine the schema for an operation implementing a different semantic convention, and competing URLs caused the builder to omit the schema entirely. Bedrock inherited the AWS RPC schema for GenAI spans and metrics until #20750 selected the GenAI schema explicitly. #20761 removed attribute-based inference in all modes; both changes are now merged into main.

The schema URL identifies the semantic convention defining a span, metric, or log. Registered attributes are reusable grab bags. Their presence does not establish a signal convention or choose, change, or invalidate the signal's schema.

Describe the solution you'd like

Use only the existing InstrumenterBuilder.setSchemaUrl(...) setter to select the schema. The instrumentation factory explicitly selects the convention defining its signal. Do not infer ownership from attribute extractors or span-name extractors, and do not introduce a new ownership API.

Keep shared schema versions in domain-owned internal definitions rather than scattering bare SchemaUrls.V... references across production instrumentation call sites. Different signal domains may intentionally adopt different versions. For configurable conventions such as RPC, select the URL using the same effective convention mode and OpenTelemetry instance as the signal implementation.

Migrate convention-defined signals before removing attribute-extractor schema providers and builder inference. Remove inference immediately in all modes, not behind v3-preview. This changes behavior for callers of the published Instrumenter API who rely on inference, so document the breaking change and migration to the existing setter.

Preserve explicit caller-supplied schema URLs. Without an explicit setter, do not assign a schema merely because registered attributes are attached. Independent event loggers and meters select the schema for their own signal convention.

Scope is semantic conventions defining spans, metrics, or logs. Exclude code-attribute-only/custom-operation schema additions and generic RabbitMQ channel-operation additions justified only by registered attributes. Generic logging-bridge attribute mapping and the separate JMX rule-engine gap remain outside this stack.

Add focused coverage showing that explicit selection propagates to exported telemetry, supporting attributes and name customization cannot alter it, and registered attributes alone do not assign a schema. Pin expected versions independently of production constants in assertions. A repository-wide assertion sweep is not a prerequisite.

Describe alternatives you've considered

  • Attribute-based inference, including first-extractor or highest-version selection. Attribute bags do not identify the convention defining a signal.
  • Inferring schema ownership from span-name extractors. Explicit declaration at the instrumentation factory is simpler and avoids coupling ownership to name wrappers and customization.
  • Bare schema versions at each call site. Domain-owned definitions avoid duplicated version policy.
  • One repository-wide schema version. Domains adopt conventions independently.
  • Restricting inference removal to v3-preview. The chosen cutover removes it in all modes and documents the breaking change.

Additional context

Status as of 2026-10-21:

All work scoped to this issue is merged into main. #20761 completed the final cutover on 2026-10-21. No remaining work was identified within this issue's scope.

#20749 tracks the broader schema audit, including the separate built-in JMX rule-engine gap. #20141 tracks repository-wide schema assertions. Neither is a prerequisite for completing this ownership change. Attribute-only findings from the original audit are not automatically missing-schema defects under this signal-based scope.

Tip

React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.

Activity

  1. self-assigned this
    on Oct 20, 2026
  2. added this to the v3.0.0 milestone on Oct 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancementNew feature or requestneeds triageNew issue that requires triage

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions