Fix Sentry child span capture by binding Hub correctly #12284
Merged
+3
−7
Conversation
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
The root cause was that `with_sentry_transaction()` created a new Hub with the transaction context, but then in `worker.rs` the code called `.bind_hub(Hub::current())` which bound the future to the original Hub instead of the new one. This meant all child tracing spans were attached to the wrong Hub that lacked the transaction context, so Sentry never saw them as children of the transaction. The fix moves the `.bind_hub(hub)` call inside `with_sentry_transaction()` so the callback future executes with the correct Hub that has the transaction, ensuring all child spans are properly associated with the parent transaction.
Turbo87
added
C-internal 🔧
LawnGnome
approved these changes
Nov 6, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
The root cause was that
with_sentry_transaction()created a new Hub with the transaction context, but then inworker.rsthe code called.bind_hub(Hub::current())which bound the future to the original Hub instead of the new one. This meant all child tracing spans were attached to the wrong Hub that lacked the transaction context, so Sentry never saw them as children of the transaction.The fix moves the
.bind_hub(hub)call insidewith_sentry_transaction()so the callback future executes with the correct Hub that has the transaction, ensuring all child spans are properly associated with the parent transaction.Disclaimer: Claude Code figured this out. At first it looked in entirely the wrong places, but once I nudged it into looking at the right areas it found the issue. I didn't trust it, so I tested it out on staging and it indeed seems to solve the problem
Before
After