Repository navigation
test(rsc): make progressive streaming e2e tests independent of fixed sleeps - #8713
Conversation
The progressive-streaming tests slept 500ms and expected the initial batch of 3 notifications to be rendered. React throttles Suspense reveals by 300ms, so the batch can legitimately land after that window. Wait for the 3rd notification, assert the stream is still open with fewer than all notifications, then wait for the next one and for completion. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
|
View your CI Pipeline Execution ↗ for commit 966ad23
☁️ Nx Cloud last updated this comment at |
🚀 Changeset Version Preview3 package(s) bumped directly, 11 bumped as dependents. 🟩 Patch bumps
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to
|
| Check name | Status | Explanation |
|---|---|---|
| Title check |  |
The title clearly and concisely describes the main change: replacing fixed sleeps in progressive streaming end-to-end tests. |
| Description check | |
The description clearly explains the problem, the test changes, the motivation, and validation results. It does not reproduce the template checklist or explicitly state the release impact, but the sub… |
| Docstring Coverage | |
No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 2… |
| Linked Issues check | |
Check skipped because no linked issues were found for this pull request. |
| Out of Scope Changes check | |
Check skipped because no linked issues were found for this pull request. |
✨ Finishing Touches
-
📝 Generate docstrings
-
- Commit to this branch
- Create a new PR
🧪 Generate unit tests (beta)
-
- Commit to this branch
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Comment @coderabbitai help to get the list of available commands.
The "Notifications stream in progressively" tests in
e2e/react-start/rsc(rsc-stream-generatorandrsc-stream-readable) clicked start, slept 500 ms, and expected the initial batch of 3 notifications to be rendered.The server sends that batch in a single chunk within ~40 ms, but React throttles Suspense reveals by 300 ms (
FALLBACK_THROTTLE_MS). When later notifications in the batch suspend briefly, they appear one throttle tick after the first (~670 ms after the click locally), which is past the 500 ms window. This is valid app behavior, so the test was asserting a timing React doesn't guarantee.It surfaced in #8708 (srvx 1.x): the Rsbuild shard failed 3/3 in CI, and passed when only this app was put back on srvx 0.10. The streamed bytes are identical between srvx versions; the different static asset serving shifts the browser timing enough to hit the throttle more often. Locally, pinned to 2 busy CPU cores, the old test fails ~50% on both srvx 0.10.1 and 1.0.5.
Change
Instead of fixed sleeps, the test now:
streaming-statusvisible) and fewer than all 7 notifications are rendered, which is what "progressive" means,The only remaining timing assumption is that the browser renders the first batch before the server finishes its 4 × 800 ms delays (~3 s margin).
Validation
tanstack-react-start-e2e-rsc:test:e2e(Vite + Rsbuild, all shards)🤖 Generated with Claude Code
Summary by CodeRabbit