Write Blade templates cache atomically #54989
Conversation
This ensures, that the file is written atomically. Otherwise, it could lead to empty files, which could lead to further errors. However, reproducing this is quit tricky, because you must compile a template and access the same template before the content is written, but after the file is created.
|
is this "bug" moot if people are correctly caching their views on deploy? |
Yes, it is a bug. Files like this should always be written atomically. Even if you pre-compile the templates before deploying the files to a production system, this is mostly not the case for testing (for example, locally). Why do you mind the change at all? Can you explain it to me so that I can understand it? |
|
A bit hesitant to change how views are written in a patch release after so many years. 😬 |
|
Same boat as Taylor. don't think the change is "wrong", but trying to weigh the risk/reward. Your original comment even said it's incredibly hard to reproduce. And if it only occurs when people are not correctly caching their views on deploy, it's not fixing a real world problem. |
This is incorrect. Mail-Templates are not compiled with the
@taylorotwell Totally understandable. However, since the problem persists even when the application is deployed correctly, it may be worth considering potential solutions, particularly for the email templates. Without having fully assessed the practicality of this, I was wondering if a (clean) pull request to extend the view:cache command to also pre-cache email templates would have a chance of being merged. Additionally, could you kindly let me know the likelihood of this request being included in the next major release (the master branch)? If it is likely, I would rebase the commit on the current master and open a new Pull Request. |
|
Thanks for the clarification. I wasn't aware mailable views weren't cached. Since your PR is so small, I'd just re-branch off of master, and try again there. You're more likely to get a response that way than on this thread. |
This change ensures that the blade cache file is written atomically. Without atomic writing, there is a brief period during which the file is created but empty. By ensuring the file is written atomically, we can guarantee that it always has a consistent state.
Reproducing this bug is quite difficult because it requires sending two requests that compile the same blade component. The second request must access the blade component before the content is written but after the file is created. To reproduce the bug, I slowed down the filesystem's write speed using the following package: https://github.com/bandwidth-throttle/bandwidth-throttle, and patched the filesystem (Patch file to reproduce; requires the Composer package bandwidth-throttle/bandwidth-throttle, which is not installed with the attached patch). Afterward, we can easily trigger the bug with PHPUnit and Parallel Testing using various tests that send the same mailable (in different tests):