fix(xpc): honor request timeouts#1965
Draft
stephenlclarke wants to merge 1 commit into
Draft
Conversation
The XPC reply continuation did not observe task cancellation, so a configured client timeout could not complete until the server replied. Resume the continuation exactly once when cancellation wins and ignore late replies. Refs: apple#1927
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.
Type of Change
Motivation and Context
apple/container#1927 documents a copy-out stall that can leave a
container cprequest waiting without a response. apple/containerization#799 addresses the guest-side lifecycle lock responsible for that stall. This PR makes theapple/containerclient's existing response timeout a reliable safeguard when a peer still does not reply.XPCClient.sendraces a timeout task against an XPC reply task. The reply task waits in a checked continuation, but an XPC reply callback does not observe task cancellation. When the timeout wins, that continuation remained suspended and the task group continued to wait indefinitely.This change uses a locked, one-shot continuation bridge: cancellation resumes it exactly once, and any later XPC reply is ignored. The scope is intentionally limited to cancellable request handling; it does not include the unrelated unknown-route behaviour proposed in #1862.
Testing
Validation
swift test --disable-automatic-resolution -Xswiftc -warnings-as-errors --filter XPCClientTests— 5/5 passed. These exercise a real anonymous XPC endpoint: response timeout, direct caller cancellation, cancellation before continuation storage, client reuse, and late replies.make test— passed: 570 tests in 71 suites (plus 94 XCTest cases).make check— passed (Swift format and license-header checks).git diff --check— passed.make APP_ROOT=… LOG_ROOT=… SCRATCH_ROOT=… all integration— executed the VM integration suite. Warmup passed; the default-width run had three unrelated TCP-forwarding retries fail. Rerunning those three serially passed. A broader serialTestCLIRunCommandrerun was blocked before execution for its other cases becauseghcr.io/linuxcontainers/alpine:3.20was unavailable in the test environment.Related