Repository navigation
fix(poll): pace long-poll reads the server answers without holding - #581
Conversation
The --wait run poll re-issues a `?waitSeconds` read immediately after every non-terminal answer, on the assumption that the server held it for up to 25s. When a proxy in front of the service answers at once instead, the loop turns into back-to-back GETs for the whole --timeout. Measure how long each long-poll read was held. A read held for at least the fallback pace (2s) is still re-issued at once; a faster one sleeps only the remainder, clamped to the --timeout deadline. No extra requests, and no change to exit codes, retryAfterSeconds or the VALIDATION_ERROR fallback. Closes TestSprite#481
|
Important Review skippedReview was skipped as selected files did not have any reviewable changes.
|
| Layer / File(s) | Summary |
|---|---|
Enforce minimum read interval src/lib/poll.ts, src/lib/poll.spec.ts |
The polling loop measures request duration and waits for the remainder of the two-second interval after an early non-terminal response. The wait is capped by the remaining timeout. Tests cover held reads, rapid responses, and timeout-clamped pacing. |
Estimated code review effort: 2 (Simple) | ~10 minutes
Change: Bug fix · Severity of issue fixed: Medium
Merge Risk: 
Minimal · previous review a3d01
-
The long-poll pacing change is mergeable after normal checks. Pacing for test-plan generation remains separate work.
Pre-merge checks: 
3 · 
2
-
Failed checks: 2 warnings Passed checks: 3 passed-
Full details: Out of Scope Changes check
-
Explanation
The changes are limited to
src/lib/poll.tsandsrc/lib/poll.spec.ts. The new exported interval, implementation logic, and tests directly support the run-poll pacing requirement in issue#481. No unrelated production behavior, dependency, or call-site changes are present.
-
Full details: Linked Issues check
-
Explanation
Issue
#481requires pacing for bothpollRunUntilTerminaland the analogoustest plan generatepolling path. This PR implements and tests thesrc/lib/poll.tslong-poll pacing: it measures the read duration, sleeps for the remaining 2-second interval, and clamps the sleep to the deadline. The diff does not modifysrc/lib/plan-poll.ts, so the plan-generation path remains unmet.Resolution
Implement the same held-time pacing and deadline clamp in the
src/lib/plan-poll.tslong-poll active-status path, and add deterministic unit tests for fast responses, held responses, and deadline clamping. Keep the existing fallback and error behavior unchanged.
-
Finishing Touches
-
Fix failing CI checks
-
- Commit to this branch
- Create a new PR
🧪 Generate unit tests (beta)
-
- 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.
ℹ️ Recent review info
-
⚙️ Run configuration
-
- Configuration used: Repository: TestSprite/testsprite-cli/.coderabbit.yaml
- Review profile: CHILL
- Plan: Advanced
- Run ID:
72607088-b63b-429b-a1e0-1eeaadd5e539
📒 Files selected for processing: 2
-
src/lib/poll.spec.ts
src/lib/poll.ts
Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 6 remain after this review.
ℹ️ Recent review info
-
⚙️ Run configuration
-
- Configuration used: Repository: TestSprite/testsprite-cli/.coderabbit.yaml
- Review profile: CHILL
- Plan: Advanced
- Run ID:
72607088-b63b-429b-a1e0-1eeaadd5e539
📒 Files selected for processing: 2
-
src/lib/poll.spec.tssrc/lib/poll.ts
Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 6 remain after this review.
-
|
🏆 Season 4 CLI Improvement Bonus: entry recorded. Thanks, @cipoklean! To be counted, this PR needs the following by Oct 29, 11:59 PM PT:
Rewards go to merged PRs judged a genuine improvement, and up to three bonus-eligible PRs count per person. Untick the box to withdraw the entry. This comment refreshes when you edit the PR. Full rules. |
What does this PR do?
The
--waitrun poll re-issues a?waitSecondsread immediately after every non-terminal answer, assuming the server held it. If a proxy answers early, the loop becomes back-to-back GETs for the whole--timeout. This adds a client-side floor: each long-poll read's held time is measured, and a non-terminal answer that returns faster than the 2s fallback pace sleeps only the remainder, clamped to the--timeoutdeadline. Held reads behave exactly as today.src/lib/poll.tslong-poll branch only;plan-poll.tsandtest.tscall sites untouched.retryAfterSecondsor theVALIDATION_ERRORfallback.Related issue
Closes #481
Season 4 CLI Improvement Bonus
Discord username: Cipoklean
Type of change
Checklist
mainbranch.npm run lintandnpm run format:checkpass.npm run typecheckpasses.npm testpasses and coverage stays at or above the 80% gate.README.md/DOCUMENTATION.mdwhere relevant.Notes for reviewers
Three tests in
src/lib/poll.spec.tswith a fake clock that the sleep spy advances: an instant-return client with a bounded read count (fails on main), a held read gets no added sleep, and the pacing sleep is clamped to the deadline (fails on main). Full suite green locally.Summary by CodeRabbit