View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011949 | Taler | wallet (iOS App) | public | 2026-11-05 02:49 | 2026-11-05 02:49 |
| Reporter | bot-cg [agent] | Assigned To | Resolution deadline | ||
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | CM_7 | |||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | normal | Severity | minor | Reproducibility | sometimes |
| Status | new | Resolution | open | ||
| Summary | 0011949: XCUITest cannot reliably drive the app: synthesized events time out because it never reports itself idle | ||||
| Description | Synthesized UI events intermittently fail against the wallet with Failed to synthesize event: Timed out while synthesizing event. XCUITest will not deliver a tap or a swipe until the app reports itself idle. This app intermittently never does, and the event is abandoned after one to four minutes. That makes XCUITest-based automation unreliable in a way that affects issues 11922 ("implement iOS test automation for Taler wallet") and 11932 ("add iOS wallet automation test for ToS acceptance prompts") — the terms of service are where it is seen most often. Measurements, from an exploration campaign on iPhone 17 / iOS 27.2, GNU_Taler debug build: * stalled actions of 48s, 74s, 79s, 117s, and event timeouts at 120s, 190s and 233s; one `swipeUp` cost 17 minutes; * two walks reduced to a single step: tapping the row that opens the terms of service, then nothing until the episode was killed at 900s; * other walks on the same build completed 31 and 50 steps with no stall at all, so it is intermittent, not a property of one screen; * where it stalls: 2 of 4 recorded stalls on the "open terms of service" row, one on a plain swipe, one on a coordinate tap. The app is not busy while this happens. `sample` of the process during two separate stalls: main thread 67% idle in mach_msg2_trap (shipping build) main thread 57% idle in mach_msg2_trap (test build, see below) with the non-idle remainder inside __XCTPerformOnMainRunLoop_block_invoke -> XCTElementSnapshotRequest loadSnapshotAndReturnError: -> accessibilitySnapshotOrError: -> AXUIElementCopyParameterizedAttributeValue i.e. servicing accessibility snapshot requests. Accessibility snapshot cost measured per screen across the campaign has a reasonable median and a very long tail: screen n median max Terms of Service 102 118ms 8.3s Loading... 1263 51ms 69.6s Wire Transfer 1474 42ms 60.9s Withdrawal 1152 37ms 118.5s Withdraw Fr. 4904 28ms 80.6s What has been ruled out ----------------------- The repeating logo animation. `RotatingTaler(once: false)` keeps Core Animation busy indefinitely, which is a plausible reason for an app never to reach idle — but a build in which that animation never runs at all stalls at exactly the same step, on the same button, with the same signature. That hypothesis is dead; I mention it so nobody spends time on it again. (The animation does ignore Reduce Motion, which is filed separately.) What is not established ----------------------- The cause. The remaining candidate is that building the SwiftUI accessibility tree for some screens is expensive enough that XCUITest's quiescence check never converges — the app is asked for a snapshot, servicing it makes the app busy, and idle is evaluated again. I have not proved that, and it may be an interaction with XCUITest rather than a defect in the wallet. Someone who knows these views will see it faster than I can from outside. This is filed because it blocks the automation work the project already has open, and because the measurements above are the kind that only turn up in a long run. It is not filed as a user-visible defect: a human using the app sees none of this. How to reproduce ---------------- 1. Build the GNU_Taler scheme for an iPhone simulator (iOS 27.2). 2. Drive it with XCUITest: accept the terms, then tap the row that opens the terms of service from the withdrawal flow. 3. Intermittently, the next synthesized event never arrives; XCUITest reports "Timed out while synthesizing event" after one to four minutes. With the UI fuzzing harness (branch dev/phoenix-bot/fuzzbang) the driver records it as an `event-stall` note and the `app-never-idle` finding, with the action and the measured duration. `sample <pid>` of the app during the stall produces the stacks quoted above; the simulator runs the app as an ordinary host process, so no attach is needed. Filed by an agent (bot-cg) on behalf of Christian Grothoff, from an automated UI exploration campaign. Left unassigned deliberately. | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||