test(node): Fix flaky thread-blocked-native worker thread test#21026
Conversation
The worker thread test was flaky on CI because it used a fixed 10s delay before blocking the event loop. On slow CI machines, the Sentry SDK polling might not have fully started within that time window. Replace the fixed delay with active polling that waits for the ThreadBlocked integration to be installed, then waits 1s for polling to start before blocking. This makes the test: - More reliable: actively verifies Sentry is ready instead of hoping - Faster: ~3s vs ~12s locally - Has a 30s timeout as a safety net Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
![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.
Reviewed by Cursor Bugbot for commit 00b79e1. Configure here.
| waitForSentryReady().then(() => { | ||
| longWork(); | ||
| }, 10_000); | ||
| }); |
There was a problem hiding this comment.
Worker checks main-only client
Medium Severity
waitForSentryReady calls Sentry.getClient() inside the spawned worker, but Sentry is initialized via --import on the parent process only. Worker isolates typically have no client, so the ThreadBlocked check never succeeds and the loop always waits the full 30s timeout before longWork(), undermining the intended early-start fix.
Reviewed by Cursor Bugbot for commit 00b79e1. Configure here.
There was a problem hiding this comment.
So far it worked quite nicely
2 participants
closes #20703
closes JS-2371
closes #20676
closes JS-2358
This was the best guess from Claude. I tried to reproduce this locally but failed. I used Docker to change the resources and lowered the CPU and memory on a reproduction. But I never reproduced the same failing state. However, this new approach is faster (Claude was very proud of that) as it is not waiting 10s, before it starts, but starts as soon as everything is set up - that also never failed locally - so it is a shot in the dark 🤞
Claude message:
The worker thread test was flaky on CI because it used a fixed 10s delay before blocking the event loop. On slow CI machines, the Sentry SDK polling might not have fully started within that time window.
Replace the fixed delay with active polling that waits for the ThreadBlocked integration to be installed, then waits 1s for polling to start before blocking.
This makes the test: