Do not report `AcceptFailed` when timing out in `stream_socket_accept()` for non-blocking listeners
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 3/5
- Geschätzter Aufwand
- 1-2 Tage
- Anfängerfreundlichkeit
- 55/100
- Issue-Typ
- Bug
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Aktiv
- Bereich
- networking
Rechercherichtung
Start at the implementation behind stream_socket_accept() and trace how a non-blocking listener with a zero timeout records stream errors. Reproduce the issue with the provided PHP script, then find the relevant stream socket tests and add coverage for the expected no-error result while preserving genuine accept failures.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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:
bool(false)
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
- Vorherrschende Sprache
- C
- Sterne
- 40.4k
- Forks
- 8.2k
- Ø Merge
- 2 T. 15 Std.
- Gemergte PRs (30 T.)
- 113
Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus php/php-src
-
Bug Status: Needs Triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
-
Bug Status: Needs Triage
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 90/100
-
Bug Status: Needs Triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
-
Flaky hrtime.phpt test OffenBug Category: Tests Status: Verified
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
-
Bug SAPI: fpm Status: Needs Triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 65/100
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 90/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
NVIDIA/k8s-device-plugin#2061 · 1 Kommentar ·
-
task
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
vsanthanam/JBird#429 ·