The mobile E2E job iOS Zig runtime slice (packages/ios/fixtures/zig-slice/build-and-run.sh) has failed twice in the last few runs, each time with the identical signature. A rerun then passed.
- #257, run 35623453695, first attempt. #257 didn't touch the fixture or any Zig source.
- #259, run 35720239483. #259 didn't touch them either.
Both runs failed with:
warning: removeSiriShortcut: +[NSUserActivity deleteSavedUserActivitiesWithPersistentIdentifiers:completionHandler:] did not call its completion within 15000 ms; answering TIMEOUT
warning: removeSiriShortcut: a deletion completion arrived 426760 ms after the call, after its deadline had answered; ignored
FAIL: timed out after 900s waiting for: i=54 i=72 i=76 i=78 i=82(On #257 the late completion arrived after 686254 ms.)
The five ids are all getDeviceInfo calls in page.m, at lines 316, 66, 276, 284 and 153. The job normally takes about 5 minutes; the failing runs took about 20.
Why it doesn't look like plain slowness: it's the same five calls every time, and a completion arrives seven to eleven minutes late. That points to the main thread, or whatever queue those replies need, being stalled for minutes. The likely stall is Siri's deleteSavedUserActivitiesWithPersistentIdentifiers, or the path that answers removeSiriShortcut after its deadline. The deadline did fire at 15 s, so the reply-slot side works. What's stuck is whatever serves the later getDeviceInfo calls.
To look at: the order of calls in page.m around those ids, and whether their replies go through the same queue the Siri completion blocks. Also whether getDeviceInfo on the Zig side touches anything the Siri deletion holds. Rerunning makes it pass, which makes it easy to ignore, and I'd rather not.