Repository navigation
fix(ios): refuse observe-only snapshots that find a system alert - #4219
Conversation
The system-alert tier answered an observe-only capture with the SpringBoard alert tree, and the response still carried observation metadata that asserts the tree came from the session app. The docs already promise no substitution, so an observe-only capture now refuses with OBSERVATION_UNAVAILABLE and a hint naming the alert. Regular snapshots keep returning the alert tree. Fold the fast and raw alert tiers into one function so the refusal has a single owner. Closes callstack#3348
Versioned help owns command semantics, so it now names the refusal. The website wording also stops implying that a success proves no alert is present.
There was a problem hiding this comment.
All reported issues were addressed across 7 files
Reply with feedback, questions, or to request a fix.
View guided diff | Re-trigger cubic
|
At de9eaf9, the code looks good. An observe-only capture now refuses a substituted system-alert tree with Not blocking, take or leave: the alert hint is a string literal at the catch site in The Coverage job is red, but its log ends mid-run without a failing assertion, and this PR changes only one help string that the unit job exercises. A rerun should settle it. No conflicts are known. |
Summary
snapshot --observe-onlycould answer with the SpringBoard alert tree while still stampingobservation, which asserts the tree came from the session app. It now refuses withOBSERVATION_UNAVAILABLEand a hint naming the alert. The docs already promised no substitution, so this refuses rather than discloses. Regular snapshots are unchanged.Closes #3348. 7 files. The fast and raw alert tiers fold into one function, so the refusal has one owner.
An alert the runner cannot read still leaves the app tree as the answer, so a success does not prove that no alert is present. The docs now say so.
Validation
pnpm check:affected --run --head de9eaf985: 13 passed, 9 skipped,exactCommit=true. Skipped includesswift-runner-ios,swift-runner-macosand the replay lanes.Unit, iPhone 17 simulator:
testObserveOnlySnapshotRefusesOnlyASubstitutedSystemAlertTreefailed before the fix and passes after.Live, same simulator, real Maps location alert, on the Swift in this PR (run before committing; later commits change only help, docs and a test assertion):
snapshotreturns the alert tree.snapshot --observe-onlyand--observe-only --rawexit 1 withOBSERVATION_UNAVAILABLE.alert dismiss,--observe-onlysucceeds withobservation.Not done: a typed reason for this refusal. The issue asks for the existing response, and the message still reads "cannot be observed without activation"; only the hint names the alert.
Independent review of
9d34cf9b1found no correctness defects.🤖 Generated with Claude Code