fix: back off failing accepts and correlate responses by id - #85
Merged
Conversation
Closes #15 and #18. Both are small changes to the same file, so they travel together rather than conflicting as separate branches. Accept loop: every accept() error was swallowed with continue, so a persistent failure — a descriptor limit being the realistic one — spun the loop at full speed forever while refusing every agent. Failures now back off from 50 ms to 1 s, and the listener stops after 64 consecutive failures. A host that exits is recoverable; a host that burns a core while silently refusing connections is not. Response correlation: the client never checked that a reply belonged to its request, and error paths answered with a literal "unknown" id. The host now echoes the id as soon as it can decode one, so validation failures are correlated too, and the client rejects anything else. The unknown-id sentinel is kept and named, because a host that could not read the request at all still has to be able to say why — that reply reaches the caller with its reason intact. Tested: a server answering with someone else's id is rejected, and a sentinel reply still arrives with its error code. The accept backoff has no test — reproducing a sustained accept failure means exhausting descriptors for the whole process, which is not worth doing to a shared test runner.
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.
Closes #15 and #18. Both are small changes to
Transport.swift; separate branches would just conflict, so they travel together.#15 — accept loop spun on failure
Every
accept()error was swallowed withcontinue. A persistent failure — a descriptor limit is the realistic one — meant the loop ran at full speed forever while refusing every agent. Now failures back off from 50 ms to 1 s and the listener stops after 64 consecutive failures (~30 s of retries).Stopping is the deliberate choice: a host that exits is recoverable and visible, a host that burns a core while silently refusing every connection is neither.
#18 — responses were correlated by convention only
LocalSocketClient.sendnever checked that the reply belonged to its request, and error paths answered with a literal"unknown"id.The host now echoes the id as soon as it can decode one, so validation failures are correlated too — previously a rejected request lost its id even though the host had successfully parsed it. The client rejects anything else.
One deliberate exception, now named rather than incidental:
CommandResponse.unknownRequestIdentifier. A host that could not read the request at all (peer rejected, unreadable frame) still has to explain why, and that reply has no id to echo. Making the check strict without it would have replaced useful errors with "mismatched response", which is worse than the bug.Tests
A server answering with someone else's id is rejected; a sentinel reply still reaches the caller with its error code intact.
The accept backoff has no test. Reproducing a sustained
accept()failure means exhausting file descriptors for the whole process, which I am not willing to do to a shared test runner for a five-line change. Saying so rather than claiming coverage I did not add.