Repository navigation
Catch up with the tree at start even while a 0.6.4 server is still stopping - #263
Merged
Merged
Conversation
The start-up catch-up was skipped outright when the thread stopping a 0.6.4 server had not finished yet. With a long --every no poll made up for it, so a --stale ask kept answering from the tree as it stood before start. The catch-up is now held until the old server is gone and runs on the first loop turn after that, ahead of any answer. The new test holds a stand-in 0.6.4 server's stop confirmation until the server has answered once, so the race reproduces on every platform rather than only under windows-latest timing. Closes #261
The loop looked at the 0.6.4 stop before handing a question over, and answer looked again. A stop that finished between the two looks let a --stale question through without being forced stale, and before the catch-up had run, so the reply came from the tree as it was before start. The catch-up now runs inside answer, on the same reading that decides staleness, and a question is forced stale only while the catch-up is still owed. The test no longer retries. It waits for the server to log that the old server stopped, then asserts that the very next --stale answer already has the document written before start. Refs #261
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.
Summary
serveno longer skips its start-up catch-up when a 0.6.4 server is still being stopped. The catch-up waits until the old server is gone, then runs on the next loop turn (withinWAKE, 250 ms), before any answer. Before this change, a--staleask under--every 3600kept answering from the tree as it was before start. That is the windows-latest flake ina_server_catches_up_with_the_tree_at_start_rather_than_at_its_first_poll.RERANK_TIMEOUTplusSTOP_WAITto leave, and a bounded wait would either hold start-up that long or still skip the catch-up when it timed out.a_server_catches_up_with_the_tree_once_a_slow_0_6_4_server_has_stopped. A stand-in 0.6.4 server holds its stop confirmation until the new server has answered once, so the race happens on every OS. The test then releases the stop and expects the document written before start to appear in a--staleanswer.Closes #261
Test plan
src/serve.rschange, the new test fails: it never catches up within 20 s.cargo test: all suites pass.cargo clippy --all-targets -- -D warnings: clean.cargo test --test servepassed 20 times in a row (20/20) on macOS.