feat: add scope merging mechanism

[giortzisg]

Description

Issues

• resolves: Add scope merging for global and isolation scopes #1369
• resolves: GO-155

Changelog Entry Instructions

To add a custom changelog entry, uncomment the section above. Supports:

• Single entry: just write text
• Multiple entries: use bullet points
• Nested bullets: indent 4+ spaces

For more details: custom changelog entries

Reminders

• Add GH Issue ID & Linear ID
• PR title should use conventional commit style (feat:, fix:, ref:, meta:)
• For external contributors: CONTRIBUTING.md, Sentry SDK development docs, Discord community

[linear-code]

GO-155

[sentry]

Bug: The NewMeter and NewLogger functions no longer return no-op instances when the client is disabled, leading to unnecessary work.
_{Severity: MEDIUM}

Suggested Fix

Reinstate the client.IsEnabled() check in the conditional logic for NewMeter in metrics.go and NewLogger in log.go. This will ensure that a no-op instance is returned when the client is disabled, preserving the original behavior and matching the documentation.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: metrics.go#L58-L59

Potential issue: The `client.IsEnabled()` check was removed from the `NewMeter` and
`NewLogger` factory functions. As a result, if the Sentry SDK is not initialized (e.g.,
no DSN is configured), these functions will now return real `sentryMeter` and
`sentryLogger` instances instead of the intended no-op versions. This causes unnecessary
CPU and memory usage to build metrics and logs that are ultimately discarded, and it
creates a mismatch between the code's behavior and its documentation, which states that
a no-op instance should be returned when the client is disabled.

Also affects:

• log.go:63~64

[cursor]

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

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

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

[sentry]

Bug: The applyTraceToEvent function only includes trace_id and span_id in the event's trace context, losing other important span metadata like op, description, and status.
_{Severity: HIGH}

Suggested Fix

Restore the previous behavior. Instead of creating a new minimal trace context, use the full context from the active span. Modify applyTraceToEvent or its calling logic to check if a span exists on the scope and, if so, use scope.span.traceContext().Map() to populate the event.Contexts["trace"] field, ensuring all span metadata is preserved.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: scope.go#L743-L756

Potential issue: When an error event is captured with an active span in the scope, the
new `applyTraceToEvent` function creates a minimal trace context containing only
`trace_id` and `span_id`. The previous implementation copied the full trace context from
the span, including `parent_span_id`, `op`, `description`, `status`, and `data`. This
change results in the loss of this critical metadata, which will break the linking of
errors to their parent transactions and operations. The code explicitly skips merging
the "trace" context from the scope at `scope.go:430`.

Also affects:

• scope.go:430~432