Summary
A WaitFor(.exists(.container(...))) failed with Cause: Could not restore the accessibility viewport after observation (viewportExitFailed, projected at HeistExecution+ResultProjection.swift:309) even though the failure interface dump shows the target screen fully displayed. Transient: the same flow passes in other runs.
Environment
- ios-register SPOS KIF suite on the heist engine (
HEIST_UITESTER=1), bazel, iPad Air (5th gen) 18.1 sim
- TheButtonHeist pinned at
fe8a25afa88a90a74adf33248b73924821112687 (main)
Evidence
Test: RKTOpenOrdersIntegrationTests test_create_order_inOrderManager_byCardDip_doesGiveTenderSelectionOption, immediately after a mock card-dip payment completes and the post-payment (receipt) flow presents.
Wait for .exists(.container(.identifier("Post Payment Flow Container"))) failed after 10.1s
Cause: Could not restore the accessibility viewport after observation
Contract: wait predicate is met before timeout
Wait evidence:
Screen changes: 3
Semantic element changes: 11
Notifications: 0
Final interface quiet: 10.1s
Observation coverage: complete
The failure interface (12 elements) is the buyer receipt screen — "How would you like to receive your receipt?", Email/Text/No receipt buttons — i.e. the post-payment flow the wait was looking for was on screen:
[2] "No change, Out of $1.00" {activate}
[3] "How would you like to receive your receipt?" staticText
[4] "Email" button id="Email Button"
[5] "Text message" button id="Phone Button"
[6] "No receipt" button
Full context (surrounding log) attached below.
Observations
- The wait reports
Observation coverage: complete and 10.1s of final quiet, yet the outcome is the viewport-restore failure rather than a predicate verdict. It looks like the viewport exit failure preempts/poisons the wait's answer, turning a should-pass wait into a fail.
- Post-payment is a heavy transition (tender flow dismissal + buyer-facing receipt presentation). We observed what looked like the same signature at other post-payment screens in an earlier census run, but that run's log was not retained, so this is the one instance I can back with evidence.
Ask
When viewport restore after an observation fails, could the wait either retry the observation or still evaluate the predicate against the (evidently complete) settled tree, rather than failing the step? Happy to run instrumented reproductions if useful.
🤖 Filed by aodawa's AI agent from SPOS census run evidence.
Summary
A
WaitFor(.exists(.container(...)))failed withCause: Could not restore the accessibility viewport after observation(viewportExitFailed, projected atHeistExecution+ResultProjection.swift:309) even though the failure interface dump shows the target screen fully displayed. Transient: the same flow passes in other runs.Environment
HEIST_UITESTER=1), bazel, iPad Air (5th gen) 18.1 simfe8a25afa88a90a74adf33248b73924821112687(main)Evidence
Test:
RKTOpenOrdersIntegrationTests test_create_order_inOrderManager_byCardDip_doesGiveTenderSelectionOption, immediately after a mock card-dip payment completes and the post-payment (receipt) flow presents.The failure interface (12 elements) is the buyer receipt screen — "How would you like to receive your receipt?", Email/Text/No receipt buttons — i.e. the post-payment flow the wait was looking for was on screen:
Full context (surrounding log) attached below.
Observations
Observation coverage: completeand 10.1s of final quiet, yet the outcome is the viewport-restore failure rather than a predicate verdict. It looks like the viewport exit failure preempts/poisons the wait's answer, turning a should-pass wait into a fail.Ask
When viewport restore after an observation fails, could the wait either retry the observation or still evaluate the predicate against the (evidently complete) settled tree, rather than failing the step? Happy to run instrumented reproductions if useful.
🤖 Filed by aodawa's AI agent from SPOS census run evidence.