Back off in the web client too, on the same schedule as Rust - #104
Merged
Conversation
Issue #48 names two targets and only one was fixed in v0.9.0. Its body says `apps/server-frontend/src/api.js` "has its own polling loop with the same shape and deserves the same treatment", and it did: a flat `POLL_INTERVAL` of 400 ms before the second question, so a job the server had already finished cost the browser that much. Worse, after the Rust half landed the browser was waiting twice as long as the CLI for the same job. Same schedule, deliberately: 10 ms doubling to a 200 ms ceiling, mirroring `apps/remote/src/waiting.rs`. `keeps_the_same_schedule_the_rust_client_uses` fails if the two ever drift, which is the failure mode that made this half worth doing rather than leaving as a nicety. Three tests. The first two spy on `setTimeout` to record what the loop asks for and fire it at once, so a schedule spanning seconds of nominal waiting is checked instantly and with no wall clock in the assertions, which is the same property the Rust side gets from its injected `Sleeper`. All three mutations are caught: starting at the ceiling, never growing, and drifting from the Rust ceiling.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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 half of #48 that v0.9.0 missed.
Why this exists
#48's body names two targets:
Only the Rust client was fixed. The browser still slept a flat
POLL_INTERVAL = 400before asking a second time, so after v0.9.0 the web app was waiting twice as long as the CLI for the same job.This was caught by an audit of the v0.9.0 release, along with the fact that
Closes #48had already fired from a commit message. #48 has been reopened with an account of what landed and what did not.The change
Same schedule as
apps/remote/src/waiting.rs, deliberately: 10 ms doubling to a 200 ms ceiling.keeps_the_same_schedule_the_rust_client_usesfails if the two ever drift. That drift is the failure mode that made this half worth doing rather than leaving as a nicety: one client quietly slower than the other, for the same server, is exactly what the issue reported.Tests
Three, and all three mutations are caught:
The first two spy on
setTimeoutto record what the loop asks for and fire it immediately, so a schedule spanning seconds of nominal waiting is checked instantly with no wall clock in the assertions. That is the same property the Rust side gets from its injectedSleeper, reached a different way because JavaScript hands you the seam for free.45 Vitest cases in
server-frontend(was 42), 116 across the repo.Closes #48