proposal to make code.stacktrace (or code.* namespace) stable

[SylvainJuge]

Area(s)

area:code

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

The code.stacktrace is currently experimental, and we think it would make sense to make it stable.

Current known usages:

• inferred-spans module in Java contrib
• span-stacktrace module in Java contrib

Making this attribute stable would allow making features that rely on it stable, relying on an experimental/incubating attribute transitively forces the feature as experimental/incubating.

Describe the solution you'd like

Making the code.stacktrace attribute stable, or making the whole code.* namespace stable.

Describe alternatives you've considered

Making the whole code.* attributes stable would be an alternative as most of those fields are not ambiguous even if some of their values are platform-specific (the code.stacktrace being a good example).

For now keeping the scope to code.stacktrace is a way to reduce the scope as an attempt to making this change easier.

Additional context

Making this attribute stable was discussed in August 29th Java SIG Meeting where the topic was "how to make a component in java contrib stable".

[SylvainJuge]

After a bit of research on trying to find usages of fields in the code.* namespace, I found that we have:

• OpenTelemetry PHP instrumentation already uses code.function, code.namespace, code.filepath and code.lineno: https://github.com/open-telemetry/opentelemetry-php/blob/068086347b41c6d31c545cf9b37e3a9a6c1ff59f/src/API/Instrumentation/WithSpanHandler.php#L39
• OpenTelemetry contrib Java use code.stacktrace in inferred-spans and span-stacktrace modules as mentioned initially in the issue description.

In addition, as described in #1012 we know that the code.function, code.filepath and code.lineno have equivalent ECS (Elastic Common Schema), so while it does not count as direct usage, usages of those equivalent ECS fields can be mapped 1:1 to otel semconv.

When searching for text occurrences of those code.* attributes to see if there are other definitions I did not find anything that would contradict the current definitions, which means there is little ambiguity or things left to interpretation.
For example, I found similar references in:

• NewRelic ruby agent: https://github.com/newrelic/newrelic-ruby-agent/blob/c71c1e38e9b3fe9e4ebd2786aa14c1e7a9d67b9b/lib/new_relic/agent/transaction/abstract_segment.rb#L135
• Sentry UI: https://github.com/getsentry/sentry/blob/4639d43292bfe72866d7edbdcaa2bd28c7bdf914/static/app/views/insights/common/components/spanDescription.tsx#L118

Also, the value and format code.stacktrace is platform-specific and might be left to ambiguity or further specification, however it uses exactly the same definition of exception.stacktrace which is already stable.