Description
Saved actions that open with launchApp (even stopApp: false) are structurally un-replayable from a mid-flow park state on an Expo dev client: the launch resets the dev client and boots the JS bundle fresh, so the navigation stack the action's first assert depends on is destroyed by the action's own prologue. A sign-flow action whose documented start state is "parked on an unsigned mandate screen deep in an onboarding stack" relaunched to Home and then failed its own opening assertVisible — every time, by construction.
Related repair-classification gap observed the same session: a registration action's terminal assert went stale from product flow drift (a push-notification prompt now precedes the home screen, and the old splash copy it matched no longer appears). The run failed with failureKind: UNKNOWN → NOT_REPAIRABLE_KIND, so auto-repair never even attempted what is arguably the most repairable failure class there is (stale terminal anchor after 56/60 steps succeeded).
Environment
| Field |
Value |
| Plugin version |
0.70.10 |
| CDP Bridge |
0.65.8 |
| OS |
Darwin 25.5.0 |
| Node.js |
v24.14.0 |
| Metro |
running on 8082 |
| iOS Simulators |
3 booted |
| Android Emulators |
0 |
| legacy agent-device |
0.17.5 (leftover install present) |
| maestro-runner |
1.1.20 |
Telemetry: stale (capture removed with the Experience Engine, GH #200).
Steps to Reproduce
- Author an action whose start state is a screen deep inside a navigation flow (not reachable from cold start), with the standard
launchApp: { stopApp: false } self-bootstrap prologue.
- Drive the app to that park state interactively.
- Replay via
cdp_run_action.
launchApp resets the dev client to the initial route; the action's first assertVisible fails with the park screen gone.
Workaround
Execute the action's steps manually via device_*/cdp_interact from the park state; or re-drive the whole flow to the park state after any launchApp.
Suggested Fix
- creating-actions guidance: park-state actions (start state ≠ cold start) must omit
launchApp entirely; add an M7 header field like entry: parked vs entry: cold so cdp_run_action can pre-flight-verify the park anchor is on screen before running (and fail with a clear PARK_STATE_MISSING instead of a step failure).
- Repair classification: a failed final assert after ≥N successful steps should be a repairable kind (stale terminal anchor), not
UNKNOWN/NOT_REPAIRABLE_KIND.
Submitted via /rn-dev-agent:send-feedback — data sanitized automatically
Description
Saved actions that open with
launchApp(evenstopApp: false) are structurally un-replayable from a mid-flow park state on an Expo dev client: the launch resets the dev client and boots the JS bundle fresh, so the navigation stack the action's first assert depends on is destroyed by the action's own prologue. A sign-flow action whose documented start state is "parked on an unsigned mandate screen deep in an onboarding stack" relaunched to Home and then failed its own openingassertVisible— every time, by construction.Related repair-classification gap observed the same session: a registration action's terminal assert went stale from product flow drift (a push-notification prompt now precedes the home screen, and the old splash copy it matched no longer appears). The run failed with
failureKind: UNKNOWN→NOT_REPAIRABLE_KIND, so auto-repair never even attempted what is arguably the most repairable failure class there is (stale terminal anchor after 56/60 steps succeeded).Environment
Telemetry: stale (capture removed with the Experience Engine, GH #200).
Steps to Reproduce
launchApp: { stopApp: false }self-bootstrap prologue.cdp_run_action.launchAppresets the dev client to the initial route; the action's firstassertVisiblefails with the park screen gone.Workaround
Execute the action's steps manually via
device_*/cdp_interactfrom the park state; or re-drive the whole flow to the park state after anylaunchApp.Suggested Fix
launchAppentirely; add an M7 header field likeentry: parkedvsentry: coldsocdp_run_actioncan pre-flight-verify the park anchor is on screen before running (and fail with a clearPARK_STATE_MISSINGinstead of a step failure).UNKNOWN/NOT_REPAIRABLE_KIND.Submitted via
/rn-dev-agent:send-feedback— data sanitized automatically