feat: add context capture API

[giortzisg]

Description

Issues

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

[sentry]

Bug: A recursive call in processEvent when handling a nil event can cause infinite recursion and a stack overflow if a noopClient is used.
_{Severity: HIGH}

Suggested Fix

Revert the logic inside the if event == nil block to call client.CaptureException(err, hint, scope) instead of making a recursive call to processEvent. This avoids the infinite loop by using the original, safe error handling path.

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: client.go#L888-L889

Potential issue: The `processEvent` function handles a `nil` event by creating a
`usageError` and making a recursive call to itself with an event generated by
`client.EventFromException`. However, when a `noopClient` is active (a common case when
Sentry is disabled or in test environments), its implementation of `EventFromException`
returns `nil`. This creates an infinite recursion loop: `processEvent(nil)` calls
`processEvent(EventFromException(...))`, which evaluates back to `processEvent(nil)`.
This will lead to a stack overflow, crashing the application.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[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 c6716f7. Configure here.}

[cursor]

Clone drops scope last event ID

Medium Severity

Scope.Clone copies boundClient and eventProcessors but not lastEventID, even though Clear retains that ID with those same fields. Forks from WithIsolation / PushScope therefore start with an empty last event ID and hide IDs already captured on the parent scope.

Additional Locations (1)

• scope.go#L347-L349

 

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

[sentry]

Bug: A call to hub.CaptureEventWithHint with a nil event will cause a panic due to a nil pointer dereference when accessing event.Type without a nil check.
_{Severity: HIGH}

Suggested Fix

Add a nil check for the event parameter before its properties are accessed. The conditional at hub.go:230 should be modified to if event != nil && event.Type != transactionType && eventID != nil { ... } to prevent the panic.

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: hub.go#L228

Potential issue: In `hub.CaptureEventWithHint`, the `event` parameter can be `nil`. New
code was added that accesses `event.Type` after `client.CaptureEvent` is called.
Although `client.CaptureEvent` handles a `nil` event internally, the original `event`
variable in the `hub.CaptureEventWithHint` scope remains `nil`. The subsequent access to
`event.Type` at `hub.go:230` therefore causes a nil pointer dereference, leading to a
panic. A user calling `hub.CaptureEventWithHint(nil, nil)` will trigger this crash.