Skip to content

feat: allow providing a hub when starting a runtime context - #2191

Merged
Litarnus merged 1 commit into
getsentry:masterfrom
binaryfire:feat/runtime-context-custom-hub
Sep 4, 2026
Merged

feat: allow providing a hub when starting a runtime context#2191
Litarnus merged 1 commit into
getsentry:masterfrom
binaryfire:feat/runtime-context-custom-hub

Conversation

@binaryfire

Copy link
Copy Markdown
Contributor

This is a small follow-up to #2190.

Some async frameworks provide their own Hub because they need Sentry scope state to follow their execution model. Hypervel, for example, keeps the Hub’s scope stack in coroutine-local storage. That keeps tags, breadcrumbs, and active spans separate between overlapping requests while still allowing child coroutines to inherit the right state.

When Hypervel starts a runtime context today, the SDK creates a regular Hub and clones its Scope. Hypervel then immediately replaces that Hub with its coroutine-aware one. It works, but the Hub and Scope Sentry just created are never used.

This PR lets a runtime pass its existing Hub directly:

SentrySdk::startContext($hub);

Sentry still creates and manages the runtime context, logs, metrics, storage, and flushing. The supplied Hub is used as-is, so the runtime remains responsible for isolating its state.

Nothing changes when a Hub isn’t provided. The SDK creates an isolated Hub exactly as it does today. Nested startContext() calls also remain no-ops and won’t replace the active Hub.

I’ve left withContext() unchanged because this is intended for frameworks that manage execution boundaries themselves. The existing FrankenPHP and RoadRunner fixtures use withContext(), so they continue to exercise the unchanged default path and don’t need updating.

Allow async runtime integrations to supply their own context-aware Hub when starting a runtime context.

Keep the default Hub cloning and nested start behavior unchanged while avoiding throwaway Hub and Scope allocations for custom runtimes.
@Litarnus

Litarnus commented Sep 4, 2026

Copy link
Copy Markdown
Contributor

Looks good, thank you!

One thing to keep in mind is that the Hub will be replaced in favour of two different types of Scopes in the near future:

  • GlobalScope - used to store data that persists between requests/units of work
  • IsolationScope - request/unit of work local data

You can take a look at this PR, it's the result of many stacked PRs. It's not 100% finalised since it needs a bit of real world testing, but it should give you the general gist of how it will work in the future.

If you have any requests for changes, feel free to open an issue/PR and we can discuss it. Since this is aimed towards the new major, you can even suggest breaking changes

@Litarnus
Litarnus merged commit 47b7ceb into getsentry:master Sep 4, 2026
51 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants