Add AlwaysStackTrace and NeverStackTrace to Tracer / TracerProvider

[AkselAllas]

What are you trying to achieve?

Get stacktraces for traces such that I can set it in my opinionated telemetry wrapper library. Such that clients for the library don't need to add their own wrapper manually.

What did you expect to see?

I need this in order to use Datadog Error Tracking.

Additional context.

open-telemetry/opentelemetry-go#8094

_{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.}

[dashpole]

Can you make this more detailed? I'm not entirely sure what "I can set it in my opinionated telemetry wrapper library. Such that clients for the library don't need to add their own wrapper manually." means.

Maybe provide more context on Datadog Error Tracking for people who aren't familiar too.

[AkselAllas]

Datadog Error Tracking is a feature, where Datadog takes Error Traces, which have stacktraces and groups them in the UI so error groups can be owned by a team, solved, muted etc.

In order for a trace to show up as an "Error", an application needs to have it's GRPC or HTTP server to have some sort of middleware which does the following:

span := trace.SpanFromContext(r.Context())
span.RecordError(err, trace.WithStackTrace(true))
span.SetStatus(codes.Error, err.Error())

As a platform engineer, I want users of the opinionated telemetry package I am writing to have to write as few boilerplate call sites as possible.

Currently there would be 3 call sites to correctly instrument Telemetry for our feature set:

1. Add telemetry.init()
2. Add http instrumentation to the http server
3. Add http middleware to the http server

I first was looking at whether I could use golang http instrumentation to set the stacktrace for the spans and skip the http middleware, but the options were not there, so I would have needed to do a PR into opentelemetry-go-contrib. But that would also not solve it for grpc servers, so I think setting AlwaysStackTrace via TracerProvider would be cleanest approach.

[dmathieu]

Looking at the exceptions spec, we can see the only required element to track exceptions/errors is the exception event.

Every other attribute is not mandatory, and a span with an exception event should still be considered as erroring even if it doesn't have them.

This therefore feels like a mismatch with the spec on the datadog side. Have you tried reaching out to them?

[AkselAllas]

@dmathieu I submitted a ticket to Datadog now using your link.

But even then I think the ability to centrally set stacktrace without requiring wrappers for separate http / grpc servers makes sense. Datadog is not the key here. You can find many reasons for wanting to do this.

[pellared]

I think it is worth mentioning that we are planning to deprecate span.RecordError. See: #4825 and https://opentelemetry.io/blog/2026/deprecating-span-events/. Therefore, I do not think we should pursue addressing this issue.

CC @open-telemetry/semconv-log-approvers

[software-artificer]

I initially came here to support this proposal, but with what you are saying here @pellared I agree that we should not be doing any of this.

My org is also using Datadog and it has been a pain point of them requiring a lot of additional information attached to a span event to surface errors properly in their dashboard. I wonder if they're aware of this upcoming change and working on this. I'll be opening up a ticket on our side to make sure they are.

[AkselAllas]

@pellared

Most companies have some sort existing functional solution for logs. And I believe therefore there are a lot of companies who don't plan on implementing the Logs API. Does that mean that those companies will not be able to make benefit of exception and stack trace events?

If so, then it doesn't sound like a very good plan to me.

[AkselAllas]

But even then, I would assume the deprecation timeline would be quite long? So we could benefit from being able to set StackTraces via SDK in the meanwhile?

[pellared]

@AkselAllas, this touches on the broader reason why we should not accept this proposal.

As outlined in the deprecation rationale for span events:
https://opentelemetry.io/blog/2026/deprecating-span-events/#why-deprecate-the-span-event-api

• Duplicate concepts for users. Operators must understand both span events and log events, how they are exported, and how their backends treat them.
• Slower evolution. Improvements to the event model must be specified and implemented in two places.

Given that span events are being deprecated, introducing new capabilities or investing further in this concept moves us in the opposite direction of that goal. It increases the surface area we’re actively trying to reduce.

More importantly, every enhancement to span events is effort that cannot be spent on strengthening the recommended path (e.g., logs/events convergence and related improvements). From a prioritization standpoint, it’s more valuable to focus on the direction we want users to adopt rather than extending one we are discouraging.

For these reasons, I don’t think this proposal should be accepted.