# Stream Error Degradation: They're now missing what can't be opened - Thread: https://externals.io/message/132097 - Original archive: https://news-web.php.net/php.internals/132097 - Started by Derick Rethans on 2026-07-24T10:51:37+00:00 - Messages: 2 - RFC: Display Function Arguments in Errors (Implemented (PHP 8.6)) — https://externals.io/rfc/display_error_function_args.md - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #132097 — Derick Rethans — 2026-07-24T10:51:37+00:00 URL: https://externals.io/message/132097#132097 Hi, Since the last few days, some of my tests for Xdebug started failing with latest master: https://xdebug.org/ci?r=2026-07-24-03-30-01@master Through commit https://github.com/php/php-src/commit/34c686a5b4ef, the filenames and dirnames are removed as argument, from the warnings/errors to include, require, etc — as a result of https://wiki.php.net/rfc/display_error_function_args While that is perhaps a noble goal, not showing which file couldn't be included in many situations, such as: Warning: include(): Failed to open stream: No such file or directory in %sinclude_path.php on line %d Warning: require_once(): Failed to open stream: No such file or directory in /tmp/ptester-1001/thread/12/master/tmp-xdebug/tests/base/bug02307-002.php on line 9 And also in many other functions: Warning: bzopen(): Failed to open stream: No such file or directory in %s on line %d Warning: dba_open(): Failed to open stream: No such file or directory in %s on line %d Warning: `finfo_open()`: Failed to open stream: No such file or directory in %s on line %d Warning: imagecreatefrompng(): Failed to open stream: No such file or directory in %s on line %d Doesn't seem to me like an enhanced for users, which would likely very much to know which file is being included/required/bzopen'ed, etc. I think we ought to fix this situations by included the file/directory that can't be opened in the error messages themselves. Or if that is not possible, then I would probably suggest to revert this change (even though it was RFC'ed) until there is a possibility for not degrading the usefulness of our error messages. cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://xdebug.cloud Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support mastodon: @derickr@phpc.social @xdebug@phpc.social --- ## #132098 — Kamil Tekiela — 2026-07-24T11:37:49+00:00 URL: https://externals.io/message/132097#132098 · In reply to: #132097 > > Hi, > > Since the last few days, some of my tests for Xdebug started failing > with latest master: https://xdebug.org/ci?r=2026-07-24-03-30-01@master > > Through commit https://github.com/php/php-src/commit/34c686a5b4ef, the > filenames and dirnames are removed as argument, from the warnings/errors > to include, require, etc — as a result of > https://wiki.php.net/rfc/display_error_function_args > > While that is perhaps a noble goal, not showing which file couldn't be > included in many situations, such as: > > Warning: include(): Failed to open stream: No such file or directory in %sinclude_path.php on line %d > Warning: require_once(): Failed to open stream: No such file or directory in /tmp/ptester-1001/thread/12/master/tmp-xdebug/tests/base/bug02307-002.php on line 9 > > And also in many other functions: > > Warning: bzopen(): Failed to open stream: No such file or directory in %s on line %d > Warning: dba_open(): Failed to open stream: No such file or directory in %s on line %d > Warning: `finfo_open()`: Failed to open stream: No such file or directory in %s on line %d > Warning: imagecreatefrompng(): Failed to open stream: No such file or directory in %s on line %d > > Doesn't seem to me like an enhanced for users, which would likely very > much to know which file is being included/required/bzopen'ed, etc. > > I think we ought to fix this situations by included the file/directory > that can't be opened in the error messages themselves. Or if that is not > possible, then I would probably suggest to revert this change (even > though it was RFC'ed) until there is a possibility for not degrading the > usefulness of our error messages. > > cheers, > Derick > > -- > https://derickrethans.nl | https://xdebug.org | https://xdebug.cloud > Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support > mastodon: @derickr@phpc.social @xdebug@phpc.social I think it's better the way it is now. The file path could leak sensitive information, and having the option to control when it is included in the error message is a good idea. However, the path is already included in some error messages, so if we want to align the behaviour that way, we can include the path in all stream error messages. But I am against reverting the change from the commit. FWIW, I always hated the stream warnings. In many situations, they duplicate the error from the main operation, and they don't provide meaningful information. For example, include already throws a warning with the name of the file being included. If the open_basedir is in effect, you will actually get 3 warnings for a single failure. Streams shouldn't be raising their own warnings and instead return an error code to the caller so that the caller can raise an appropriate message.