Judge a worker by how its requests end, not only by their handlers - #301

The consecutive-error breaker retires a worker after three failing requests in a row, and it decides what "failing" means from flags the request fiber's own zend_catch raises. Everything that happens after the request handler returns is outside that arm, and PHP runs it behind guards of its own — so for the whole shutdown window the breaker was not merely blind, it was reading the wrong answer.

A request that came apart there arrived at the check with no flag raised at all. That is the branch that reads a healthy worker and clears the run. So an application fataling in its shutdown function on every request was, to this mechanism, the picture of health, and one alternating between a fatal in its handler and a fatal in its shutdown function held the count at one for the life of the process. The same held for an exception thrown there.

What changed

Four outcomes at the end of a request are now classified the way the same outcome in the handler already was.

Thirteen lines of code in ext/oxphp_fiber.c. The witnesses were already there and already being read: both CG(unclean_shutdown) sites repair the abandoned frames by hand, which is the definition of a request that came apart, and the exception is already reported a few lines below.

The deadline needs its own handling because max_execution_time is the one cancellation the interrupt handler never sees — the engine calls zend_timeout() ahead of it. Every other cancellation is marked before it unwinds, so it survives whatever swallowed the bailout; this one is recognised by its connection_status bit in the handler arm, which a shutdown-window bailout bypasses. Counting it would rotate the whole pool three requests at a time for an application that defers work to the end of a request and reaches a dependency that has gone slow.

That bit is only read for a request that had not already come apart, and this is the subtle half. It is raised once and stands for the rest of the request, while the bailout flag beside it is lowered by every repair — so on its own it answers "did this request's deadline ever expire", not "did the deadline end this window". Without the guard, a handler fatal followed by a shutdown function outliving the remaining deadline would be filed as a cancellation, erasing a failure already established correctly, and handing any application a way to keep a permanently broken worker in the pool by registering one slow shutdown function.

Tests

Seven sequences appended to the worker-mode breaker profile, each ending in a probe that reads Worker::current()->requestCount() together with oxphp_worker_recycles_by_reason_total{reason="error"} — 29 suite entries, taking the profile from 23 to 52.

Three of the seven are what actually discriminates, and they are the mixed ones. A block of three identical neutral outcomes passes just as well on a build that reads them as successes, because clearing the count does not retire a worker either. Only a neutral outcome dropped into a run of fatals separates "did not count" from "wiped the count". The same asymmetry the profile already had between its cancellation blocks.

Every change in this PR was arrived at by a red test on the build immediately before it, in a chain of five images that differ by one edit each:

One trap is worth repeating because the fixture looked right and was not. The destructor case first declared a class directly inside __destruct; PHP rejects that while the file is compiled ("Class declarations may not be nested"), so the fatal happened at include time, inside the handler's own arm, where the outcome is already counted — the block passed on a broken build and only the log showed why. It now reaches E_COMPILE_ERROR at runtime through a require of a helper that declares a class at top level. The point at which the destructor runs was confirmed separately with a non-fataling destructor writing markers: handler returning → shutdown function ran → destructor ran.

Verification

• breaker 52/52
• default 242/242, fibers 32/32, timeout 8/8, bailout 2/2
• worker 54/56 — the two errors are shared/test_channel_fanin_waker and shared/test_channel_async_usevar_stress, known stress flakes; a control run of the same profile on an unmodified image produces the same two
• cargo fmt --check, cargo clippy --all-targets --no-default-features -D warnings, cargo test --no-default-features — all clean

Notes for review

• exit() and die() in a shutdown function are untouched: both throw an unwind exit rather than bailing out, so no flag is raised for them and such a request still counts as one that completed. The throw flag explicitly excludes unwind and graceful exit for the same reason.
• Traditional, framework and SPA serving have no worker to recycle and are unaffected.
• Two sibling arms at the very end of the request loop still recover from a bailout without marking anything — a __toString that fatals while an exception is reported, and a userland output handler that fatals during the end-of-request flush. Same class, left out of this change deliberately and tracked separately.