Repository navigation
0.83.2: control-plane accept loops pause after accept errors - #377
Merged
Merged
Conversation
- tw-control: add accept_backoff. An accept error other than a refused, aborted or reset connection (for example EMFILE) now waits one second before the next accept, on both the local control socket and the remote control port, matching axum on the gateway ports. Retrying at once returned the same error and spun a CPU core. - The local loop takes the result out of select! before sleeping, so the future stays Send. - sync.rs: the two comments added with #372 follow the file's language. - Version 0.83.2 with release notes covering #372 and this change. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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
Same class of defect as #372, found while reviewing it: a background loop that can wake immediately forever.
accept_loopon the local control socket (lib.rs) and on the remote control port (remote.rs) logged an accept error and accepted again at once. For errors that are not about the one connection (for exampleEMFILEwhen core runs out of file descriptors) the nextacceptfails the same way, so the loop spun a CPU core and wrote a warning per iteration.accept_backoff: refused, aborted and reset connections are skipped right away; any other accept error waits one second before the next accept. This matches what axum already does on the gateway ports.select!before sleeping, so thewatch::Reffromwait_foris not held across the await and the future staysSend.sync.rs: the two comments added in fix(sync): stop idle CPU spin after local configuration changes #372 now follow the file's language.Validation
cargo fmt --all -- --check,cargo clippy --locked --workspace --all-targets -- -D warningscargo test --locked --workspace: 4097 passed, 0 failed, including the newaccept_errors_pause_unless_only_that_connection_went_awayand fix(sync): stop idle CPU spin after local configuration changes #372'searly_round_returns_consume_the_dirty_deadlinepython3 scripts/release_notes_test.py🤖 Generated with Claude Code