feat: allow providing a hub when starting a runtime context - #2191
Merged
Litarnus merged 1 commit intoSep 4, 2026
Merged
Conversation
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.
Contributor
|
Looks good, thank you! One thing to keep in mind is that the
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
approved these changes
Sep 4, 2026
This was referenced Sep 5, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
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 usewithContext(), so they continue to exercise the unchanged default path and don’t need updating.