fix: shield worker error handlers from request-parsing warnings

[dunglas]

Fixes #2631

Problem

In worker mode, request parsing (post_max_size overflow, max_input_vars exceeded, malformed multipart payloads...) happens inside frankenphp_handle_request(), between two requests, where the worker script's persistent userland error handler is live. Under a throwing handler (symfony/error-handler, i.e. every stock Symfony app in worker mode), the E_WARNING becomes an uncaught ErrorException: the callback is never invoked, the worker script dies and restarts, and the client receives a 200 with an empty or fatal-dump body. Any unauthenticated client can restart workers at will by POSTing a form with more than max_input_vars fields.

Classic SAPIs never had this problem because input parsing runs before the script starts, when no userland error handler exists.

Fix

1. The userland error handler is bypassed while PHP parses the request. During the startup parse window, EG(user_error_handler) is temporarily unset so every diagnostic routes to zend_error_cb and reaches the log, exactly as under PHP-FPM or Apache. The callback then runs with truncated input, matching classic SAPI behavior. The restore mirrors zend's own pattern (Zend/zend.c): if userland code running inside the window (e.g. session.auto_start with a user save handler) registers a new handler, the new handler wins.

2. Diagnostics raised during that window are recorded by a zend_error_cb wrapper (installed once per Init() on the PHP main thread; recording is gated by a thread-local flag, and the wrapper always chains to the original callback). Entries are stored with malloc/strdup so they survive bailouts and stay invisible to the per-request allocator.

3. New PHP function frankenphp_request_parse_errors(): array exposes them, shaped like error_get_last() ({type, message, file, line}), empty array on a cleanly parsed request. Works in both worker and classic modes, so frameworks can reject unparsable requests with a 400/413 instead of processing truncated input:

$handler = static function () {
    if (frankenphp_request_parse_errors()) {
        http_response_code(400);

        return;
    }

    // ...
};

Notes

• A callback argument was considered but rejected: the first callback argument is already used by the message-worker API, and overloading it would force type-sniffing in userland. An early 4xx answered by FrankenPHP itself was also rejected as it diverges from classic SAPI and non-worker behavior; frameworks opt in instead.
• frankenphp_arginfo.h regenerated with php-src's gen_stub.php (PHP-8.5 branch), which also modernized the existing ZEND_FALIAS entries to ZEND_RAW_FENTRY.
• symfony/runtime can now replace the error-mask workaround proposed in [Runtime] Reject unparsable requests with a 400 response in FrankenPhpWorkerRunner symfony/symfony#65761 with a check of this function in FrankenPhpWorkerRunner.

Tests: TestWorkerSurvivesRequestParseErrors reproduces the exact Symfony scenario (throwing ErrorException handler) and proves worker survival across both failure types via a request counter, plus reset between requests; TestRequestParseErrors_module covers classic mode.

[AlliBalliBaba]

TBH not a fan of the error_get_last() request flow. Wouldn't it be possible to just do something like this?

while($continue) {
  try {
    $continue = frankenphp_handle_request($handler)
  } catch(\Exception $e) {
    // handle error
  }
}

[AlliBalliBaba]

If we plan to modify the worker api, I'd rather do something that gives us more control, like this:

$server = new \FrankenPHP\Server()

$server->onRequest(function() {
  // ...
})->onMessage(function() {
  // ...
})->onError(function() {
  // ...
});

$server->run();

[dunglas]

Your first suggestion would be a BC break.

I like the second one but it's a brand new API, the benefit of the current approach is that it's BC break free and inline with existing PHP functions.

If we introduce a new API, it could even be:

new HttpWorker(onRequest: $callback, onError: $callback, onMessage: $callback);

It could also be nice to add a hook to execute code after a request.

[AlliBalliBaba]

Your first suggestion would be a BC break.

It would just be a change on the Symfony side. But I realized that the try-catch does nothing since the exception is already caught by frankenphp_handle_request. So the worker does not really restart, at least in this case:

frankenphp_log("starting up");

set_error_handler(function ($errno, $errstr, $errfile, $errline) {
    throw new Exception($errstr);
});

while (frankenphp_handle_request(function(){
    echo "Hello World";
})) {}

To get the same behavior as with FPM, you'd need to not forward the error and instead reset the the error handler briefly on each request. Kind of what you were already doing, but passing the error is unnecessary.