feat(metrics): Associate trace data with metrics

[szokeasaurusrex]

Set trace and span id on metrics.

Stacked on #1026

Co-authored-by: Joris Bayer joris.bayer@sentry.io
Closes #1058
Closes RUST-186

[linear-code]

RUST-186 Add trace metric tracing association in sentry-core

[github-actions]

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against 3d71e21

[lcian]

We should fall back on the propagation context to get the span ID, as it seems the Python implementation does it that way: https://github.com/getsentry/sentry-python/blob/5d26c2f60e289c89ab260ee25607a3bea5e174c9/sentry_sdk/scope.py#L1828.

I saw that logs do the same and only consider self.span, so we should probably fix that too.

[lcian]

This could also return just Metric. If we need to have before_send_metric (not sure if that exists) then I guess Option<Metric> makes sense though. It's an internal API anyway so it doesn't really matter.

[lcian]

LGTM other than the comment about span_id.

[cursor]

Redundant double get_span() call in apply_to_metric

Low Severity

apply_to_metric calls self.get_span() twice, each time cloning the Option<TransactionOrSpan>. For the Transaction variant, this also results in get_trace_context() being called twice (once explicitly for trace_id, once internally via span_id()), each acquiring a mutex lock and cloning the full TraceContext. A single get_span() call, stored in a local variable, would avoid the redundant cloning and lock acquisitions. The sibling method apply_to_log already follows this pattern by checking self.span.as_ref() once.

 

^{Reviewed by Cursor Bugbot for commit 9f8e156. Configure here.}

[cursor]

Inconsistent visibility between noop and real apply_to_metric

Low Severity

apply_to_metric is pub(crate) in real.rs but pub in noop.rs. Every other scope method (apply_to_log, apply_to_event, set_span, get_span, etc.) uses pub consistently in both implementations. This breaks the established pattern and means the method's external accessibility changes depending on whether the client feature flag is enabled.

Additional Locations (1)

• sentry-core/src/scope/noop.rs#L125-L126

 

^{Reviewed by Cursor Bugbot for commit 9f8e156. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 3 total unresolved issues (including 2 from previous reviews).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 3d71e21. Configure here.}

[cursor]

Metric span_id doesn't fall back to propagation context

Medium Severity

In apply_to_metric, trace_id falls back to self.propagation_context.trace_id when no active span exists, but span_id does not similarly fall back to self.propagation_context.span_id — it just becomes None. This is inconsistent within the method itself (trace_id has a fallback but span_id doesn't), inconsistent with apply_to_event (which sets both trace_id and span_id from the propagation context when no span is active), and inconsistent with the Python SDK reference implementation. The test assertions for is_none() appear to encode the wrong expected behavior.

 

^{Reviewed by Cursor Bugbot for commit 3d71e21. Configure here.}