fix!(core): Make HubSwitchGuard !Send to prevent thread corruption#957
fix!(core): Make HubSwitchGuard !Send to prevent thread corruption#957szokeasaurusrex wants to merge 7 commits intoszokeasaurusrex/envelope-into_itemsfrom
Conversation
szokeasaurusrex
force-pushed
the
szokeasaurusrex/hubswitchguard
branch
from
21b407b to
1dea844
Compare
szokeasaurusrex
changed the title
szokeasaurusrex
force-pushed
the
szokeasaurusrex/hubswitchguard
branch
from
e78483a to
8abf004
Compare
szokeasaurusrex
force-pushed
the
szokeasaurusrex/hubswitchguard
branch
from
8abf004 to
1255c8a
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
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.
szokeasaurusrex
force-pushed
the
szokeasaurusrex/hubswitchguard
branch
from
0976b79 to
e4ddd01
Compare
|
This current implementation is still flawed; if the same span is re-entered in the same thread (possible in async contexts), the second entry overwrites the original HubSwitchGuard, corrupting the behavior. I am working on a fix |
|
@szokeasaurusrex it rewrites the original guard with the same one I think, so what's the issue there? |
|
I've tested some scenarios manually and didn't find any issues. I assume you're also testing manully. |
|
@lcian Codex AI agent identified the potential issue here as I was working on #946. I have a test locally which reproduces the behavior. Will commit it with a more detailed explanation of the problem tomorrow 👍 I suppose it's possible that Codex is wrong and the local test is doing something which is not supposed to ever happen (the scenario is admittedly a bit contrived), but in any case, I think it's worth it to investigate properly. So, that is what I'm doing now. I will let you know if I need any assistance |
HubSwitchGuard manages thread-local hub state but was Send, allowing it to be moved to another thread. When dropped on the wrong thread, it would corrupt that thread's hub state instead of restoring the original thread. To fix this, add PhantomData<MutexGuard<'static, ()>> to make the guard !Send while keeping it Sync. This prevents the guard from being moved across threads at compile time. Additionally, refactor sentry-tracing to store guards in thread-local storage keyed by span ID instead of in span extensions. This fixes a related bug where multiple threads entering the same span would clobber each other's guards. Fixes #943 Refs RUST-130 Co-Authored-By: Claude <noreply@anthropic.com>
szokeasaurusrex
force-pushed
the
szokeasaurusrex/hubswitchguard
branch
from
e4ddd01 to
6169b08
Compare
szokeasaurusrex
changed the base branch from
master
to
szokeasaurusrex/envelope-into_items
2 participants
Description
HubSwitchGuardmanages thread-local hub state but wasSend, allowing it to be moved to another thread. When dropped on the wrong thread, it could corrupt that thread's hub state instead of restoring the original thread.This PR makes
HubSwitchGuard!Sendby addingPhantomData<MutexGuard<'static, ()>>while keeping itSync. The type system now prevents the guard from being moved across threads at compile time.To ensure guards are always dropped on the originating thread,
sentry-tracingnow stores them in thread-local storage keyed by span ID rather than in span extensions.Issues