From 95659f4685d4f95a10845cd84ecdb703f39a08d3 Mon Sep 17 00:00:00 2001 From: Paul Hitt Date: Tue, 25 Aug 2026 16:30:00 -0400 Subject: [PATCH] Record the two reproducible iOS pair symptoms in PARITY Both reproduce on an idle machine, so neither is load. One-way delivery between two fresh accounts, and a group create that throws while the sheet sits open. The evidence that rules out the first wrong theory is written down with them, so nobody re-derives it. Co-Authored-By: Claude Opus 5 --- PARITY.md | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/PARITY.md b/PARITY.md index 4b2d3a5..b629064 100644 --- a/PARITY.md +++ b/PARITY.md @@ -357,3 +357,30 @@ profile; nothing in this repository can do it, and nothing here should try. 2026-08-23 — so `:app:assembleRelease` produces a signed APK that can go straight to a tester. That asymmetry is why Android reaches testers first, and it has nothing to do with which app is more finished. + +## Two reproducible symptoms in the iOS pair (2026-08-25) + +Found running `TwoSimulatorUITests` against `relay1`. **Both reproduce with the +machine idle**, so neither is the load artifact they were first taken for. + +**1. One-way delivery between two fresh accounts.** Alpha receives bravo's +message — test1 passes on alpha's side, 113s. Bravo never shows alpha's, across +a full three-minute wait, on two separate runs. The direction is stable. + +Already ruled out: `E2EInbox.transmit` throws before recording anything when the +recipient has no device, and `send` appends to the thread only *after* +`transmit` returns. So alpha's line existing in alpha's thread is positive +evidence the relay accepted envelopes addressed to bravo's device. Bravo +therefore either never fetched them or could not open them. ⚠️ The first reading +of this — "the app records messages it could not deliver" — was **wrong**, and +reading `E2EInbox` is what disproved it. Do not act on that theory. + +**2. Creating a group does not produce a group.** The sheet stayed open past two +minutes; the tree captured at failure shows Home, the buddy row present, and the +Groups section reading "No groups yet. Start one with your buddies." +`createGroup` appends to `groups` on success and `groups` is `@Published`, so a +successful create would have rendered a row. It did not — the create threw. + +⚠️ Both concern sending **to** the second account. Suggestive, not a diagnosis. +The next run needs the thread dump (added) plus the relay's own view of what is +queued for that device.