correct #545's causal claim: the hardware run refuted it - #546
Merged
Conversation
I ran the hardware test #545's own comments promised, and it did not confirm them. Correcting the record where the wrong claim lives, not only here. WHAT #545 CLAIMED. That an iPhone "routinely arrives on an IPv6 link-local address, and that is why `remote_lan_used_at` stayed null through real LAN use." WHAT I MEASURED, 2026-09-07, this Mac, a paired client on the same Wi-Fi, peer address read at the socket: arm A pre-#545 binary -> 192.168.1.104 latch FIRED arm B post-#545 binary -> 192.168.1.104 latch FIRED Both arrivals were IPv4, never `fe80::`. `classify` and `classifyPeer` are byte-identical for RFC 1918, so that arrival cannot distinguish the two at all — inconclusive for the IPv6 change, exactly as the pre-registered protocol said an IPv4 arrival would be. AND THE HISTORICAL NULL HAD A SIMPLER CAUSE. The Mac app's card read **0 paired** until I paired a phone with it during this run. No phone had ever completed a handshake with the shipping app. The earlier sessions ran against an XCTest-hosted agent, where `AnonymousTelemetryCoordinator.shared` is nil and nothing is reported regardless of address. So the null was never evidence of a classification bug. WHAT THE RUN DID ESTABLISH, and it is worth having: · the chain works end to end — connection → classifyPeer → remoteTransportUsed → RPC → `anonymous_installs.remote_lan_used_at`, observed non-null on production, `last_seen_at` moved from Sep 3 to now; · #545 does not regress the IPv4 path; · the emitter is live in both bundles. THE FIX STAYS. fe80::/10, fc00::/7 and 169.254/16 ARE the same network when a phone arrives on one, and `classify` returning nil for them would under-count. That is an argument from address semantics, proven by `LANPeerClassificationTests` — not from an observed fleet miss, and it must not be cited as one. Both comments now say so. Production left as found: the probe's `remote_lan_used_at` was written by a Simulator on this same Mac, not by a phone on a network, so it was nulled back. The row is kept — it carries genuine install history. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The hardware run could not exercise #545's IPv6 change: on this Wi-Fi a client resolving Bonjour arrived on IPv4 both times, and `LANDirectAddress.parse` rejects `%`, so a link-local address cannot be typed into connect-by-address either. The one path left is to make the connection myself. These drive a real `NWListener` over the real TLS-PSK parameters and read what `LANLinkAgent`'s own function sees, rather than asserting on a string literal the way `LANPeerClassificationTests` does: · a real connection to this Mac's own `fe80::…%en0` is accepted, `remoteHost` observes an `fe80:` literal, `classifyPeer` returns `.lan`, and the advertise-side `classify` still returns nil for the same string. That is #545's claim, end to end, on a real socket. · loopback stays unclassified — pinning that the wiring is live AND that its answer there is the intended nil, so the first test cannot pass by everything being `.lan`. IT ALSO CLOSES A GAP THE REVIEW FLAGGED. `remoteHost` had no test at all, and it reads `conn.currentPath?.remoteEndpoint` — not `conn.endpoint` — with `currentPath` not documented to be populated when `.ready` fires. If it were nil there the latch could never fire, and that failure is indistinguishable from "classified to nil" and from "accept never ran": three causes, one non-observation. Measured: it IS populated. Now pinned.⚠️ Two of my own mistakes worth leaving in the record, because both presented as product failures: 1. `remoteHost` is MainActor-isolated (its owner is a `@MainActor` class), so calling it from the listener queue traps with `fatalError`. Production hops via `Task { @mainactor }` inside `accept`; the test must too. 2. Having hopped, waiting on a semaphore from the test body DEADLOCKS — XCTest runs on the main actor, which is exactly the thread the hop needs. It presents as "the connection never reached .ready", which reads like a transport bug. The helper is `async` and polls instead; the header says so. Full CLIPulseCore suite: 3007 tests, 4 skipped, 0 failures. SwiftLint clean. Co-Authored-By: Claude Opus 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 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.
I ran the hardware test #545's own comments promised. It did not confirm them,
so this corrects the record — and then proves the fix a different way, since
the network would not produce the arrival the original claim assumed.
1. Measured, 2026-09-07 — peer address read at the socket
192.168.1.104(IPv4)192.168.1.104(IPv4)Never
fe80::.classifyandclassifyPeerare byte-identical for RFC 1918,so an IPv4 arrival cannot distinguish them — inconclusive for the IPv6 change,
exactly as the pre-registered protocol said an IPv4 arrival would be.
2. The historical null had a simpler cause
The Mac app's card read 0 paired until I paired a phone during this run.
No phone had ever completed a handshake with the shipping app. The earlier
sessions ran against an XCTest-hosted agent, where
AnonymousTelemetryCoordinator.sharedis nil and nothing is reportedregardless of address. The null was never evidence of a classification bug.
3. So the IPv6 half is proven on a real socket instead
LANDirectAddress.parserejects%, so a link-local address cannot be typedinto connect-by-address either — the only way to get one is to make the
connection.
LANPeerHostObservationTestsdrives a realNWListenerover thereal TLS-PSK parameters and reads what
LANLinkAgent's own function sees:fe80::…%en0is accepted,remoteHostobserves an
fe80:literal,classifyPeerreturns.lan, and theadvertise-side
classifystill returns nil for the same string;everything being
.lan.It also closes a gap the review flagged:
remoteHosthad no test, and itreads
conn.currentPath?.remoteEndpointwithcurrentPathnot documented tobe populated at
.ready. If it were nil there the latch could never fire, andthat is indistinguishable from "classified nil" and "accept never ran".
Measured: it is populated. Now pinned.
What the whole exercise establishes
classifyPeer→remoteTransportUsed→ RPC →anonymous_installs.remote_lan_used_at,observed non-null on production with
last_seen_atmoving Sep 3 → now.fe80::is observed and counted correctly on a real connection.which is a question about networks, not about this code.
Housekeeping
Production left as found: the probe's
remote_lan_used_atwas written by aSimulator on this same Mac, not a phone on a network, so it was nulled back.
The row is kept — it carries genuine install history.
Full CLIPulseCore suite: 3007 tests, 4 skipped, 0 failures. SwiftLint clean.
🤖 Generated with Claude Code