config/view.php "cache" option does not work and causes views to render blank randomly

[stellar-scottreed]

Laravel Version

11.22

PHP Version

8.3.14

Database Driver & Version

No response

Description

I set the "cache" option in config/view.php to "false" (#41859)
With this set this way, laravel is still generating views in storage/framework/views. Additionally, we had an extremely difficult to trace bug that this caused where views would randomly return an empty string. This was especially seen under concurrency.

Steps To Reproduce

Look in the storage/framework/views folder when cache in config/view.php is set to false.

Also, I set up a nodejs script to fetch from a route with 5x requests at the same time and it would frequently return empty string instead of "it works!". When I removed the "cache" option in config/view.php this issue stopped occuring.

[rodrigopedra]

If you look at the linked PR's code (#41859), setting cache to false will make the blade compiler to always report the views as expired.

The compiler will always generate the PHP version of a view, that is what gets executed at the end, but when setting cache to false it will regenerate the file on every request.

From your description, it seems you are getting a race condition with many requests trying to write the same compiled view file, as each request thinks it is expired and tries to regenerate it again.

As the view is not changed the hash for each request, its hash will result the same, and as each request race for the same file, some might be getting locked.

As stated in the linked PR, this option is meant to be used during development, where these high-concurrency scenarios are unlikely to happen.

What is the use-case where you need the view to be regenerated for every request?

Mind that, with the current implementation, skipping writing the generated PHP from a view to a file is not an option.

[rodrigopedra]

If all you want to avoid writing files to the disk, in a scenario like deploying to an immutable container, you can try setting the environment variable VIEW_COMPILED_PATH to a directory under /tmp, and make sure your /tmp is mounted as a tmpfs mount (assuming your server runs on Linux).

tmpfs means /tmp will be mounted to your RAM, so the blade compiler will "write" those compiled PHP files into your RAM, which is much faster than your disk and should improve the race condition scenario.

Mind that in a hugely concurrent scenario, you can still get locks. If there are many requests waiting to "write" the regenerated view into memory, the OS lock timeout might take longer than the requests awaiting.

I have no clue if you can have a partition or drive mapped to memory on Windows.

macOS should behave the same as Linux, but I am not sure.

---

EDIT: added a possible scenario where avoiding writing to disk might be wanted.

[stellar-scottreed]

@rodrigopedra Thank you for the quick reply! I really don't need "cache" set to false in production, and I've removed that. What happened is that I had a Laravel 5.4 codebase which had "cache" set to false (don't ask me why), which had no effect since the toggle wasn't introduced until Laravel 9. I upgraded to Laravel 11 and started having this issue in production, and finally traced it to that flag when I thought to disable view caching to try to fix it... and then I was very surprised to see view caching was disabled and that was the entire problem!

I wanted to submit a bug report in case there was something to prevent this for others, if not at least the search engines will index this and someone else can find this if they have this happen!