Description
The following code:
<?php
$server = stream_socket_server(
'tcp://127.0.0.1:0',
context: stream_context_create([
'stream' => [
'error_mode' => StreamErrorMode::Silent,
'error_store' => StreamErrorStore::All,
],
]),
);
stream_set_blocking($server, false);
var_dump(stream_socket_accept($server, 0));
foreach (stream_last_errors() as $error) {
var_dump($error);
}
Resulted in this output:
bool(false)
object(StreamError)#3 (5) {
["code"]=>
enum(StreamErrorCode::AcceptFailed)
["message"]=>
string(35) "Accept failed: Connection timed out"
["wrapperName"]=>
string(6) "stream"
["severity"]=>
int(2)
["terminating"]=>
bool(true)
}
But I expected this output instead:
While it is technically true that accepting a new connection failed, no clients waiting is an expected situation when using a non-blocking listener socket (in particular with a zero-timeout). It is a common pattern to call accept() until no more client connections are returned to quickly drain the listening queue after the polling API marked the listener as readable instead of sending it through the whole polling logic again.
By treating the timeout as a failure with the generic AcceptFailed error code, it becomes impossible to distinguish this situation from genuine failures (such as exhausted file descriptors) without inspecting the message, which is particularly annoying when combined with StreamErrorMode::Exception and greatly diminishes the ergonomics of PHP 8.6’s new polling API and stream error handling logic.
PHP Version
PHP 8.6.0-dev (cli) (built: Sep 24 2026 09:04:46) (NTS)
Copyright © The PHP Group and Contributors
Zend Engine v4.6.0-dev, Copyright © Zend by Perforce
with Zend OPcache v8.6.0-dev, Copyright ©, by Zend by Perforce
Operating System
No response
Description
The following code:
Resulted in this output:
But I expected this output instead:
While it is technically true that accepting a new connection failed, no clients waiting is an expected situation when using a non-blocking listener socket (in particular with a zero-timeout). It is a common pattern to call
accept()until no more client connections are returned to quickly drain the listening queue after the polling API marked the listener as readable instead of sending it through the whole polling logic again.By treating the timeout as a failure with the generic
AcceptFailederror code, it becomes impossible to distinguish this situation from genuine failures (such as exhausted file descriptors) without inspecting themessage, which is particularly annoying when combined withStreamErrorMode::Exceptionand greatly diminishes the ergonomics of PHP 8.6’s new polling API and stream error handling logic.PHP Version
Operating System
No response