Repository navigation
Bind the companion fixture to a loopback alias in CI - #419
Merged
Merged
Conversation
The simulator's TCP connects to the fixture on a hosted runner's 192.168.64.x NAT address drop now and then (#418), which is what made the companion check flaky. The fixture binary now takes an optional bind address as its second argument, kept to private IPv4 addresses because the phone's pairing parser accepts only those; without one it binds to the LAN address as before. CI sets CHAT_IOS_FIXTURE_IP to 10.255.255.1, and the test script adds that alias to lo0 when absent, passes it to the fixture, and removes it on exit. Loopback never drops a SYN, so the warm-up becomes a formality. Closes #418 Co-Authored-By: Claude Fable 5.1 <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 join this conversation on GitHub.
Already have an account?
Sign in to comment
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 #418
The simulator's TCP connects to the fixture on a hosted runner's
192.168.64.xNAT address drop now and then (POSIX 60 on run 38000133677), which is what made the companion check flaky and what #417 could only mitigate. This takes the fixture off that interface.companion-fixturetakes an optional bind address as its second argument (fixture::bind_address), limited to private IPv4 addresses because the phone'sPairing.parseaccepts only those and rejects127.0.0.1; without one it binds to the LAN address as before. Three unit tests cover accepted, refused and empty requests.CHAT_IOS_FIXTURE_IP=10.255.255.1; the test script adds that alias tolo0when absent, passes it to the fixture, and removes it on exit. Local runs without the variable are unchanged.docs/iphone-companion.mddocuments the variable.Governed files are untouched (
Cargo.toml,Cargo.lock,lib.rs,ci.yml), so no repin follows.Verification
Full-flow runs on this branch (
ui_flowon), fixture athttps://10.255.255.1. Runs 1 and 2 passed; run 3 was cancelled by the workflow's concurrency group when this PR opened on the same branch, not failed, so the UI-flow gate from #417 stays until three green full runs exist (being gathered onmainafter this merge):Host gates on Rust 1.95:
cargo test --all-features --lib283 passed, 6 ignored;cargo clippy --all-targets --all-features -D warningsandcargo fmt --checkclean;shellcheckon the script.Note on the warm-up:
simctl openurlto a self-signed HTTPS address returns non-zero once Safari refuses the certificate, which the script reports as "could not open … within 45s" even when it took far less; that is Safari, not the network. With the fixture on loopback the warm-up is a formality and can be trimmed later.🤖 Generated with Claude Code