Add coroutine-safe Sentry runtime contexts

[binaryfire]

Summary

This PR makes Sentry Logs and Trace Metrics safe to use in Hypervel's concurrent Swoole workers.

It adopts the runtime-context APIs added in getsentry/sentry-php#2190 and getsentry/sentry-php#2191. Hypervel supplies coroutine-local storage, its coroutine-aware Hub, and the execution boundaries, while the SDK continues to own the runtime context resources and flush behavior.

The Sentry dependency temporarily tracks dev-master because these APIs have been merged but haven't been included in a tagged release yet.

Motivation

Hypervel already isolates Sentry scopes between coroutines through its custom Hub. Sentry Logs and Trace Metrics were different: their buffers belonged to the SDK's process-wide runtime context, so concurrent requests or jobs could add to and flush the same buffers.

The package documented those features as unsupported and used explicit flushes around scope and job cleanup. Those flushes couldn't provide isolation, and some ran before all child coroutine work had finished.

The SDK now exposes the pieces needed for the framework to model this directly. A Hypervel execution can have one Sentry runtime context, and that context can stay alive until the execution and its application child coroutines are done.

Design

The integration starts a runtime context at each framework-owned execution boundary:

• HTTP requests;
• queue jobs;
• scheduled tasks;
• WebSocket opening callbacks;
• WebSocket messages;
• WebSocket closing callbacks.

Nested boundaries in the same coroutine reuse the active context. Root console telemetry continues to use the SDK's global context and is flushed when the application terminates.

Runtime contexts are stored in CoroutineContext. When an execution creates child coroutines, they keep the existing eager snapshot of the parent's Sentry scope and request, but share the execution's Logs and Metrics buffers. A small counted holder keeps the context alive until the last owner exits, at which point the SDK flushes it once.

The holder implements NonCopyableContext, so general context copies can't duplicate ownership without retaining it. Sentry's explicit child hook is the only path that shares the holder. The hook also handles repeated Testbench registration without retaining the same child twice.

Hypervel passes its existing coroutine-aware Hub directly to SentrySdk::startContext(). This avoids constructing a throwaway SDK Hub and Scope at every execution boundary. Child coroutines don't construct another runtime context, Hub, Scope, or pair of telemetry aggregators.

Sentry delivery coroutines are marked before child startup hooks run. They skip scope, request, and runtime-context propagation, so sending an envelope can't inherit or flush application telemetry.

WebSocket lifecycle

The WebSocket server now dispatches two guarded lifecycle events:

• ConnectionOpening after the bridged request is installed and before handshake validation or routing;
• ConnectionClosing before handler resolution and onClose().

These fill the two gaps where the existing events happened after application code had already started or completed. Both use hasListeners() guards, so unused events create no event object and perform no dispatch.

The existing error, cancellation, and cleanup behavior is preserved. Opening failures still follow the handshake rendering path, while closing listener failures are reported without skipping later close callbacks. Cancellation stops later callbacks but still releases connection state.

Flushing and shutdown

Execution-end flushing replaces the explicit flushes previously attached to scope pops, failed jobs, and scheduled-task terminal events. This keeps telemetry buffered for the complete execution and lets the final runtime-context owner flush it once.

Integration::drainEvents() now uses the SDK flush facade to publish Logs and Metrics before performing Hypervel's bounded wait for accepted pooled deliveries. Graceful queue shutdown and worker-exit drains retain their existing bounded behavior. Application termination doesn't flush the global context while a bounded execution context is still active.

The old internal Integration::flushEvents() path and its duplicate Logs/Metrics flush code are removed.

Configuration and compatibility

The existing middleware, facade, configuration keys, tracing behavior, and pooled transport API remain intact.

The deprecated enable_logs and enable_metrics keys remain for Sentry Laravel configuration compatibility, but the SDK no longer uses them as feature switches. The documentation now points to before_send_log and before_send_metric when an application needs to discard that telemetry. Trace Metrics return to the SDK's default configuration.

Sentry remains independent of the WebSocket Server package. The provider registers optional event class names without adding a package dependency.

SDK state registered by Hypervel is reset from the shared PHPUnit cleanup subscriber so it can't leak between application lifecycles. The full parallel suite also exposed a Horizon niceness test that permanently changed a reusable worker's priority; that test now runs in a separate process and asserts the change from its inherited baseline.

Performance

Inactive Sentry applications register no execution listeners or child propagation hook. WebSocket applications without listeners only pay a guarded listener lookup and don't construct events or contexts.

Benchmarks showed the active child path without a parent context remained within measurement noise, while the Sentry delivery path improved after removing repeated context lookups and cloning. A child inside an active execution adds about 1.2 microseconds for one retain, one context write, one defer, and the matching release. It doesn't create SDK runtime objects.

An active WebSocket callback pays the fixed cost of one SDK runtime context and its Logs and Metrics aggregators. That work only occurs when Sentry is active and is required to isolate telemetry between concurrent messages.

Verification

• PHP formatting and both static-analysis configurations.
• Focused Sentry, WebSocket Server, WebSocket instrumentation, test-cleanup, and Horizon coverage.
• Full parallel component suite.
• Testbench package-mode suite.
• Dogfood application suite.
• Before-and-after coroutine and WebSocket lifecycle benchmarks.