[Bug]: Using `--parallel` causes overall process to fail with no reporting as to why even though all tests pass

[ConorEdwardsCP]

What Happened

Our team noticed after upgrading to Pest 4 that our tests running in parallel are showing all tests as passing, but having the overall command fail. However, if we run the exact same test suite sequentially, we get the same number of passing tests and the overall command passes.

Sequential

./vendor/bin/pest --exclude-group=fails-in-parallel  --testsuite=Feature --compact

  ................................................................................................................................................................
  ............................................................................

  Tests:    236 passed (364 assertions)
  Duration: 139.51s

echo $?
0

Parallel

./vendor/bin/pest --exclude-group=fails-in-parallel  --testsuite=Feature --parallel

  ................................................................................................................................................................
  ............................................................................

  Tests:    236 passed (364 assertions)
  Duration: 30.20s
  Parallel: 12 processes

echo $?
2

How to Reproduce

1. Run test suite without --parallel flag and see it passes with the same number of tests and assertions
2. Run test suite with --parallel flag and see it returns an error code of 2, even though it shows the same number of tests and assertions passing successfully

Sample Repository

No response

Pest Version

4.0.3

PHP Version

8.4.11

Operation System

macOS

Notes

I'm not certain if it's related, but I've also noticed that when we run tests in parallel now and there is a test failure, it is swallowing the error and immediately killing the tests without reporting anything about what caused the failure. There was a previous issue #1451 that hinted at their problem could be related to the master process not properly handling the exit codes of the worker threads, which feels like it could be a reason for both of these issues.

[ConorEdwardsCP]

For the record, my only indication it's related to Pest 4 is that we didn't have this issue at all when running it on Pest 3. I also am not super familiar with what I can do to help debug or print out any errors related to the process, so if there's anything I can do to help give information let me know!

[thomas-0816]

see #1462

[chrispmcgee]

I am running into this same problem now, and it is preventing us from upgrading to Pest 4. Are there any plans to address this?

October 2025 update: Still broken in v4.1.2
December 2025 update: Still broken in v4.1.6
January 2026 update: Still broken in v4.3.1

[chrispmcgee]

see #1462

Is there something actionable in this link that can be used to fix or work around this issue?

[uintaam]

The changes in #1462 do not solve this issue for me. We are still seeing a exit code 1 that does not occur in Pest 3 we are running via artisan php artisan test --parallel --display-deprecations or ./vendor/bin/pest --parallel --display-deprecations

[chrispmcgee]

It's 2026, and this is still broken in Pest v4.3.1.

[chrispmcgee]

Root cause identified and fixed (Pest v4.4.1 / PHPUnit 12)

After extensive debugging, we traced this to a combination of two PHPUnit 12 changes:

1. Exit code 1 with all tests passing

PHPUnit 12 changed the default for failOnPhpunitWarning from false to true. The exit code calculation in ShellExitCodeCalculator now checks hasPhpunitWarnings(), which includes both testTriggeredPhpunitWarningEvents and testRunnerTriggeredWarningEvents.

In parallel mode, any PHPUnit extension that fails to bootstrap in the master process produces a testRunnerTriggeredWarningEvent. In our case, ergebnis/phpunit-slow-test-detector fails because the EventFacade is already sealed when it tries to register subscribers. This is invisible — no warning is printed — but it sets the warning flag and flips the exit code to 1.

Fix options:

• Remove the offending extension from phpunit.xml (we removed ergebnis/phpunit-slow-test-detector)
• Or set failOnPhpunitWarning="false" in phpunit.xml (preserves the extension but suppresses the exit code)
• Check for any other extensions in your <extensions> block that may not be parallel-safe

2. Yellow ! marks in compact output (bonus)

If you're also seeing yellow ! marks (rendered as N in PHPUnit 12's progress output), these are PHPUnit Notices — a separate issue. PHPUnit 12 now warns when createMock() is used without configuring any expectations (expects()). The fix is to use createStub() instead for mock objects that only use ->method()->willReturn().

Debugging approach

If you're hitting exit code 1 and want to identify your specific cause, add this after the Result::exitCode() call in vendor/pestphp/pest/src/Plugins/Parallel/Paratest/WrapperRunner.php:

// Temporary debug — dump to file to see what's flagged
file_put_contents('/tmp/pest-debug.txt', implode("\n", [
    'wasSuccessful: ' . var_export($testResultSum->wasSuccessful(), true),
    'hasPhpunitWarnings: ' . var_export($testResultSum->hasPhpunitWarnings(), true),
    'testRunnerWarnings: ' . count($testResultSum->testRunnerTriggeredWarningEvents()),
    'testTriggeredWarnings: ' . count($testResultSum->testTriggeredPhpunitWarningEvents()),
]));

This will tell you whether it's testRunnerTriggeredWarningEvents (extension bootstrap failures) or testTriggeredPhpunitWarningEvents (test-level warnings).

[zenlex]

Happening for me too when using --parallel + sharding - all tests pass, no phpUnit debug config issues and I see the 'misuse of shell builtins' on the passing of --processes arg. I monkey patched the sharding in CI temporarily to strip the --processes arg and am still seeing a 100% test passing rate with nonzero exit codes causing CI to report as a failure. No notices no warnings.

[User7142]

We hit this repeatedly on a ~5500-test suite and could reproduce + root-cause it. It is not about worker exit codes — it is failOnEmptyTestSuite firing on a merged result that falsely claims the suite was empty:

1. Each wrapper worker's serialized TestResult only carries the numberOfTests of the last file it executed (PHPUnit's Collector overwrites the counter on every executionStarted).
2. If a worker's final file has all tests excluded by --group/--exclude-group, that worker reports hasTests() === false despite having run many tests.
3. If all workers end on such a file (timing lottery → flaky), the merged result in WrapperRunner::complete() claims "no tests".
4. PHPUnit 12 turns failOnEmptyTestSuite on implicitly for explicit selections (Merger::hasExplicitTestSelection()), so the run exits 1 — with a fully green summary, because the "No tests found" runner warnings are filtered from the output.

Deterministic minimal repro (two files, one process):

# ATest.php: one test in group "filtered-group"; ZTest.php: one test without group
php bin/pest --parallel --processes=1 --group=filtered-group path/to/dir
# prints "Tests: 1 passed", exits 1

Proposed fix in #1757: treat a worker with numberOfTestsRun() > 0 as having tests when merging. Workaround until then: add --do-not-fail-on-empty-test-suite to parallel runs that use group filters (and assert a minimum test count out-of-band if you need the empty-suite protection).