-
Notifications
You must be signed in to change notification settings - Fork 7.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disable realpath cache for ZTS builds #15600
Comments
This might indeed be a FrankenPHP issue. Maybe @dunglas can have a look at this? |
This is possible but unlikely. This may be a ZTS issue, but FrankenPHP itself does nothing specific regarding files / the FS. |
Hmm, might be a realpath cache issue. @g-ra, please disable the realpath cache ( |
it seems the setting worked for us, I don't quite understand how this parameter will affect the performance of our application? we initially assumed that the problem was in docker volumes, but it seems we were wrong and you were right, will this bug be fixed in future versions? |
Well, the realpath cache is a feature, since it caches expensive |
Oh, forgot, maybe SAPIs/extension which inherently use on ZTS builds could do that themselves, or at least document the issue. |
Thanks for the explanation @cmb69. It's the first time an issue related to realpath cache has been reported to our bug tracker. Maybe could we improve the documentation to explain how the user can clear this cache if necessary. Do you know if calling Disabling entirely the cache will likely have a negative performance impact on most users. |
Calling If users delete files which are in the realpath cache of other threads, and having the realpath cache enabled, can only work if they apply some locking ( |
Description
What happened?
Description:
I'm encountering an issue where file writing operations using fwrite occasionally fail when running under FrankenPHP. Sometimes files are not physically created on the server, but the filesize and file_exists functions report them as existing correctly. The code is designed to handle image uploads encoded in Base64, and it works reliably in development environments (e.g., Docker for Windows, Docker for Mac). However, under FrankenPHP in production, files are often missing, even though all the code logic suggests they should have been created successfully.
Issue: Intermittent file creation failures with fwrite. Sometimes files are not physically created on the server, but the filesize and file_exists functions report them as existing correctly.
Expected Behavior: The file should be consistently created with the correct size, matching the decoded Base64 data.
Observed Behavior: The file is either not created physically on the server, without throwing any exceptions or errors in some cases.
The code above shows that we try to handle all possible errors in production and log them (Grafana, Sentry), but no exceptions are being thrown inside the code, the file sizes are reported correctly, and the file is said to exist. However, in reality, the file is physically missing. How could this happen? Where could the file be stuck? Is fwrite being altered by FrankenPHP?
What complicates things is that we cannot reproduce this error in the development environment—10 out of 10 messages are processed without errors. The issue only occurs on the production server, about every other time. The configurations are the same as those specified in the API Platform documentation.
We have verified that base64_decode is functioning correctly; the content is decoded properly.
Versions:
FrankenPHP: 1.2.4
API Platform: 3.3.11
PHP: 8.3.10
Build Type
Worker Mode
No
Operating System
GNU/Linux
CPU Architecture
x86_64
PHP configuration
details
Relevant log output
No response
PHP Version
PHP 8.3.10
Operating System
No response
The text was updated successfully, but these errors were encountered: