Always send traces on error

[Aareksio]

Problem Statement

When tracesSampleRate is used, traces may not be included with the error. When working on a real world™ application, the operator may be incentivized to greatly reduce sample rate to prevent clutter and cost overrun. At the same time, traces may prove useful for analyzing the errors.

Solution Brainstorm

Similar concern has already been raised in #10812, for that particular use case, "Session Replay" was a viable solution, the issue was closed as completed. However, JavaScript SDK can also be used in an environment in which Session Replay is not viable - eg. in node.js runtime.

From the discussion in the mentioned issue I understand current architecture decides whether to keep or discard the trace at the head. Perhaps this could be re-evaluated, especially as v9 already seem to include some minor changes to sampling.

The goal with this Feature Request is to keep track of the idea, especially as the competition has introduced similar capability per #10812 (comment)

[Lms24]

Hey @Aareksio thanks for writing in! At this point there are no plans to rework our tracing approach to this behaviour. Among many things, one of the most important reasons as to why we head-sample is that in case of a negative sampling decision, there's much less performance overhead than in a positive decision if we don't actually record all the data points. If we were to sample tail-based within the SDK, you'd always pay the performance overhead price. This is by the way the same in Session Replay to an extent.

I haven't tested this extensively but given that most of OpenTelemetry instrumentation sets a span status, you can give filtering transactions based on their status a try:

Sentry.init({
  tracesSampleRate: 1.0,
  beforeSendTransaction: (txnEvent) => {
    const status = txnEvent.contexts.trace?.status;
    if (!status || status === "ok") {
      return null;
    }
    return txnEvent;
  },
});

I'll close this issue as I don't think we'll change our sampling model in the SDK in near future.