fix(thread-pool): report a bootloader failure through the worker's error stream

[EdmondDantes]

A ThreadPool bootloader that throws had two ways out of the worker, and both are private to whoever submits tasks: the message is kept for the next submit(), and the tasks already queued are rejected with the exception. A pool driven as a set of long-lived workers reads neither. The HTTP server submits one internal task per worker and awaits it only for completion, so the exception was dropped and the process exited 0 with nothing on stdout, nothing in error_log, and no worker ever having served.

The worker now hands the exception to zend_exception_error() before it closes the pool. That is the same call the engine makes for an uncaught exception at the end of a request, so display_errors, log_errors, error_log and error_reporting all apply, and the output reads as usual:

PHP Fatal error:  Uncaught RuntimeException: boot failed! in /app/boot.php:12

zend_exception_error() adds E_DONT_BAIL, so the worker still reaches the close-and-reject path and every existing consumer sees what it saw before. set_exception_handler() is not invoked: the exception is reported, not dispatched.

The bailout branch (exit() in the bootloader, or a fatal error) keeps its silence — a fatal error has already printed itself on the way to the bailout, and exit() is not an error.

Tests

080-bootloader_exception_reported.phpt is new: a pool whose bootloader throws, with nothing submitted at all, must still produce the fatal. 063-bootloader_exception.phpt keeps its assertion that the message reaches the awaiter and now also expects the report.

Locally: ext/async, 1230 tests, 3 failures — curl/063, curl/064, io/082. None of them creates a ThreadPool, so this change cannot run in them.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!