You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Three follow-up notes from the human review of #3336 (reviewer comment 2026-10-08T22:38:43Z; the lane-policy layer shipped there is row 8's subject matter in #2491). None blocks the PR; all three outlive it, so they live here instead of a comment thread.
Scope
Scope the re-issue predicate to declared reads.runStep in test/integration/ios-simulator-e2e/live-harness.ts attaches isObservationPreventedStepMiss to EVERY iOS step. A replay step's failure response is the failed step's OWN wire response passed through verbatim (readLastResponse() in packages/replay-port/src/daemon-port/native-command.ts), so a nested wait's retriable: true + details.reason hoists to the top level and could re-run a whole script after earlier mutating steps. Today that is benign (every lane replay starts with open --relaunch or launchApp clearState), and it cannot stack with the test suite's --retries: a scheduler-level suite failure is built as errorResponse(code, message) without details/retriable (packages/replay-port/src/daemon-port/test-command.ts), and a completed-with-failures suite returns ok:true counts the harness asserts itself. The scoping rule the reviewer proposed: re-issue only steps whose command declares the read effect (resolveCommandRecordingEffect(step) === 'observes-app'), so hoisting can never reach a mutating step even after fixture changes.
Make absorbed misses countable. A re-issue that turns a step green records the first failure only inside step-history.json (runtime.tsrunStep, issue > 1). One stderr line or JUnit annotation keyed on the typed reason (error.details.reason + retriable) would let ci(ios): the iOS simulator smoke lane is failing on main across several rotating signatures #2491 count absorbed misses per class instead of grepping step histories.
Build the retry-policy fixtures from the wire, not by hand.waitFailure() in test/integration/ios-simulator-e2e-step-retry-policy.test.ts hand-writes the response shape. It currently matches the recorded payload (run 37356199982: top-level retriable: true, details.reason: wait_runner_restart_exhausted), but building fixtures via normalizeError or a recorded CLI payload keeps them honest if the envelope moves.
Why
Three follow-up notes from the human review of #3336 (reviewer comment 2026-10-08T22:38:43Z; the lane-policy layer shipped there is row 8's subject matter in #2491). None blocks the PR; all three outlive it, so they live here instead of a comment thread.
Scope
runStepintest/integration/ios-simulator-e2e/live-harness.tsattachesisObservationPreventedStepMissto EVERY iOS step. Areplaystep's failure response is the failed step's OWN wire response passed through verbatim (readLastResponse()inpackages/replay-port/src/daemon-port/native-command.ts), so a nested wait'sretriable: true+details.reasonhoists to the top level and could re-run a whole script after earlier mutating steps. Today that is benign (every lane replay starts withopen --relaunchor launchApp clearState), and it cannot stack with thetestsuite's--retries: a scheduler-level suite failure is built aserrorResponse(code, message)withoutdetails/retriable(packages/replay-port/src/daemon-port/test-command.ts), and a completed-with-failures suite returns ok:true counts the harness asserts itself. The scoping rule the reviewer proposed: re-issue only steps whose command declares the read effect (resolveCommandRecordingEffect(step) === 'observes-app'), so hoisting can never reach a mutating step even after fixture changes.step-history.json(runtime.tsrunStep, issue > 1). One stderr line or JUnit annotation keyed on the typed reason (error.details.reason+retriable) would let ci(ios): the iOS simulator smoke lane is failing on main across several rotating signatures #2491 count absorbed misses per class instead of grepping step histories.waitFailure()intest/integration/ios-simulator-e2e-step-retry-policy.test.tshand-writes the response shape. It currently matches the recorded payload (run 37356199982: top-levelretriable: true,details.reason: wait_runner_restart_exhausted), but building fixtures vianormalizeErroror a recorded CLI payload keeps them honest if the envelope moves.Related: #2491, #3336.