WritableResourceStream::handleWrite() enters infinite loop on broken TLS socket (EPIPE without PHP warning)

Bắt đầu trong src/WritableResourceStream.php tại guard của handleWrite() quanh dòng 151, sau đó lần theo cách các kết quả của fwrite() và các cảnh báo được bắt lại ảnh hưởng đến bộ đệm ghi và listener. Tái hiện bằng một ReactPHP SecureServer và một máy khách TLS bị kết thúc đột ngột trong khi các thao tác ghi đang được xếp hàng. Được xem là hoàn tất khi một lần ghi trả về false mà không có cảnh báo sẽ đóng stream, còn lần ghi trả về zero vẫn giữ nguyên hành vi hiện có phụ thuộc vào cảnh báo và không còn gây ra vòng lặp CPU.

On PHP 8.x with react/socket's SecureServer (TLS), when a remote client disconnects abruptly, epoll reports EPOLLOUT|EPOLLHUP on the dead socket FD. WritableResourceStream::handleWrite() calls fwrite(), which returns false because the kernel write() returns -1 EPIPE. However, PHP's OpenSSL stream wrapper does not call php_error_docref() for SSL_ERROR_SYSCALL+EPIPE errors in all code paths. The set_error_handler capture therefore gets nothing ($error === null).

The guard evaluates to false, so close() is never called. WritableResourceStream then silently passes false to substr() (implicit cast to 0 in non-strict mode), leaving the write buffer unchanged and the write listener active. epoll keeps returning EPOLLOUT|EPOLLHUP, fwrite() keeps returning false silently - 100% CPU lockup.

Reproduction: use react/socket SecureServer with TLS, kill a client with kill -9 while the server has queued writes to that client.

Fix: separate the $sent === false case (hard error - always close) from $sent === 0 (may be transient EAGAIN/WANT_WRITE - only close when PHP warning is present):

// Before
if (($sent === 0 || $sent === false) && $error !== null) {

// After
if ($sent === false || ($sent === 0 && $error !== null)) {

This issue was investigated with the help of AI, but the 100% CPU usage issue is real and after applying the above fix on production, it seems to have disappeared.