Skip to content

Commit a0e78ee

Browse files
committed
fix(workflows): address Copilot review feedback on continue_on_error
- Reword README "Error Handling" intro in terms of `StepStatus.FAILED` halting by default, with non-zero shell/command exit as one common cause. Avoids implying only exit codes can halt a run (gate aborts and validation failures also do, just via different mechanisms). - Tighten `test_validation_accepts_bool_continue_on_error` to assert `errors == []` instead of "no error mentions continue_on_error", so unrelated validation regressions on the same minimal YAML can no longer slip past this test. - In `test_gate_abort_still_halts_with_continue_on_error`, swap `sys.stdin` itself for a stub `_TTYStdin` instead of patching `sys.stdin.isatty`. Method-on-instance assignment is unreliable on real `io.TextIOWrapper` objects (e.g. under pytest with capture disabled), so replacing the whole stdin object is more robust across runners. All 2967 tests still pass.
1 parent 3708adf commit a0e78ee

2 files changed

Lines changed: 17 additions & 9 deletions

File tree

tests/test_workflows.py

Lines changed: 9 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -2322,7 +2322,14 @@ def test_gate_abort_still_halts_with_continue_on_error(
23222322
# Force the gate step into interactive mode and feed a "reject"
23232323
# choice so the abort path actually runs in the test env
23242324
# (default behaviour returns PAUSED when stdin is not a TTY).
2325-
monkeypatch.setattr(gate_module.sys.stdin, "isatty", lambda: True)
2325+
# Swap sys.stdin itself for a stub: setattr on the real
2326+
# TextIOWrapper's `isatty` method is not assignable under some
2327+
# runners (e.g. pytest with capture disabled).
2328+
class _TTYStdin:
2329+
def isatty(self) -> bool:
2330+
return True
2331+
2332+
monkeypatch.setattr(gate_module.sys, "stdin", _TTYStdin())
23262333
monkeypatch.setattr(
23272334
GateStep, "_prompt", staticmethod(lambda _msg, _opts: "reject")
23282335
)
@@ -2399,9 +2406,7 @@ def test_validation_accepts_bool_continue_on_error(self):
23992406
continue_on_error: {yaml_value}
24002407
""")
24012408
errors = validate_workflow(definition)
2402-
assert not any(
2403-
"continue_on_error" in e for e in errors
2404-
), errors
2409+
assert errors == [], errors
24052410

24062411

24072412
# ===== State Persistence Tests =====

workflows/README.md

Lines changed: 8 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -221,11 +221,14 @@ Aggregate results from fan-out steps:
221221

222222
## Error Handling
223223

224-
By default, a non-zero exit code from any step halts the entire run.
225-
Set `continue_on_error: true` on a step to record its result and
226-
continue to the next sibling step instead. The exit code remains
227-
available on `steps.<id>.output.exit_code` so downstream `if`,
228-
`switch`, or `gate` steps can branch on it:
224+
By default, any step that ends in `StepStatus.FAILED` halts the entire
225+
run — most commonly a `shell` or `command` step exiting non-zero, but
226+
also things like a step type that fails validation. Set
227+
`continue_on_error: true` on a step to record its result and continue
228+
to the next sibling step instead. When the failure was a non-zero
229+
exit, the exit code remains available on
230+
`steps.<id>.output.exit_code` so downstream `if`, `switch`, or `gate`
231+
steps can branch on it:
229232

230233
```yaml
231234
- id: heavy-thing

0 commit comments

Comments
 (0)