You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the ocante:frankenphp command receives a SIGTERM signal, it gracefully stops the frankenphp server via the caddy admin API. That works fine.
However, the frankenphp-worker.php script does not receive this signal, and it will simply be terminated.
try {
// omitting for brevitywhile ($requestCount < $maxRequests && frankenphp_handle_request($handleRequest)) {
$requestCount++;
}
} finally {
// THIS PART IS NEVER CALLED.$worker?->terminate();
gc_collect_cycles();
}
It appears that the worker hangs during the call to frankenphp_handle_request()
This is problematic, because $worker->terminate is responsible for firing the WorkerStopped event which is commonly used for clean-up tasks.
// sentry for laravelprotectedstatic$octaneEventHandlerMap = [
// ommited for brevityOctane\WorkerStopping::class => 'octaneWorkerStopping',
];
I'm not sure if this is an issue in frankenphp_handle_request, or in the integration with octane. Maybe frankenphp_handle_request should not block when the caddy server has been stopped (@dunglas)?
Or perhaps the octane CLI command should somehow communicate to the worker script that no new requests will be incoming.
In practice, this means that using WorkerStopping is unreliable for any form of zero-downtime deployment with graceful shutdowns.
As Laravel is an open source project, we rely on the community to help us diagnose and fix issues as it is not possible to research and fix every issue reported to us via GitHub.
If possible, please make a pull request fixing the issue you have described, along with corresponding tests. All pull requests are promptly reviewed by the Laravel team.
Octane Version
2.5.9
Laravel Version
11.31.1
PHP Version
8.3.13
What server type are you using?
FrankenPHP
Server Version
1.3.1
Database Driver & Version
sqlite
Description
When the
ocante:frankenphp
command receives aSIGTERM
signal, it gracefully stops the frankenphp server via the caddy admin API. That works fine.However, the
frankenphp-worker.php
script does not receive this signal, and it will simply be terminated.It appears that the worker hangs during the call to
frankenphp_handle_request()
This is problematic, because $worker->terminate is responsible for firing the
WorkerStopped
event which is commonly used for clean-up tasks.// default octane.php config WorkerStopping::class => [ CloseMonologHandlers::class, ],
I'm not sure if this is an issue in
frankenphp_handle_request
, or in the integration with octane. Maybefrankenphp_handle_request
should not block when the caddy server has been stopped (@dunglas)?Or perhaps the octane CLI command should somehow communicate to the worker script that no new requests will be incoming.
In practice, this means that using
WorkerStopping
is unreliable for any form of zero-downtime deployment with graceful shutdowns.Steps To Reproduce
Add this line to frankenphp-worker.php
Start frankenphp via
octane:frankenphp
and then send aSIGTERM
to the process.The log message will not be printed.
The text was updated successfully, but these errors were encountered: