Skip to content

fix: honor all stop-on-* flags in parallel mode#1684

Open
stsepelin wants to merge 1 commit into
pestphp:4.xfrom
stsepelin:fix/parallel-stop-on-failure
Open

fix: honor all stop-on-* flags in parallel mode#1684
stsepelin wants to merge 1 commit into
pestphp:4.xfrom
stsepelin:fix/parallel-stop-on-failure

Conversation

@stsepelin

@stsepelin stsepelin commented Apr 23, 2026

Copy link
Copy Markdown
Contributor

What:

  • Bug Fix

Description:

In parallel mode only --stop-on-failure was honored, and only when a worker exited with a non-zero code. The seven other stop-on-* flags (--stop-on-defect, --stop-on-error, --stop-on-risky, --stop-on-incomplete, --stop-on-warning, --stop-on-notice, --stop-on-deprecation, --stop-on-skipped) were silently ignored - the test suite carried on to completion regardless.

WrapperRunner now precomputes the set of progress-file characters that should trigger a stop (F, E, R, I, W, N, D, S) from the configured flags, and scans each worker's progress file for them after every cycle. Once any matching outcome is seen, the pending queue is cleared so no further tests are dispatched.

Known limitation: up to N - 1 in-flight tests (where N is --processes) can still complete after the first stop-worthy outcome. Interrupting them mid-run would risk corrupting shared state (databases, fixtures, temp files), so they are allowed to finish.

Integration coverage lives in tests/Visual/Parallel.php with a shared fixture at tests/.tests/ParallelStopOn/ — one Has*Test.php trigger per outcome type plus a Passing/ subdir of ten passing fixtures. A --filter regex selects exactly one trigger alongside the passing set per scenario, keeping the fixture DRY.

Related:

Closes #1463.

@stsepelin stsepelin force-pushed the fix/parallel-stop-on-failure branch from bed7a3d to 853e4af Compare May 4, 2026 07:38
@nunomaduro

Copy link
Copy Markdown
Member

how paratest its own parallel runner handles this?

Previously --stop-on-failure was the only flag honored in parallel
mode, and it only cleared pending tests when the exit code was
non-zero. The rest (--stop-on-defect, --stop-on-error, --stop-on-risky,
--stop-on-incomplete, --stop-on-warning, --stop-on-notice,
--stop-on-deprecation, --stop-on-skipped) were silently ignored.

WrapperRunner now precomputes the set of progress-file characters that
should trigger a stop (F, E, R, I, W, N, D, S) based on the configured
flags, and scans each worker's progress file for them after every
cycle. Once any matching outcome is seen, the pending queue is cleared.

Up to N-1 in-flight tests (where N is --processes) can still complete
after the first stop-worthy outcome — stopping them mid-run would risk
corrupting shared state.

Closes pestphp#1463.
@stsepelin stsepelin force-pushed the fix/parallel-stop-on-failure branch from 853e4af to 3100b64 Compare June 28, 2026 21:28
@stsepelin

Copy link
Copy Markdown
Contributor Author

Hi @nunomaduro,

Thanks for your review, and sorry for the delay.

Paratest's runner only stops the entire run with --stop-on-failure (keyed to the worker exit code). It forwards the other flags to the workers but never acts on them at the dispatch level. This PR keeps the same $this->pending = [] mechanism but widens the trigger via progress-file scanning (since the exit code can't detect risky/incomplete/skipped/etc.).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: Pest 4.0.2 stop-on-failure continues on failure instead of stop

2 participants