Expired view cache check causing issues with my deployment script

[jlswanson28694]

Laravel Version

10.48.22

PHP Version

8.1.2

Database Driver & Version

No response

Description

I use a simple deployment bash script that runs git pull followed by some cache commands, including php artisan view:cache. This can often result in the last modified timestamp of a Blade file having the same timestamp as its corresponding compiled view. Laravel's view compiler uses a >= comparison when checking if the compiled view is expired, which means all the views compiled in my deployment script aren't being used. Is there a reason why it can't use a > comparison instead?

https://github.com/laravel/framework/blob/11.x/src/Illuminate/View/Compilers/Compiler.php#L112

Steps To Reproduce

• Use a bash script to pull changes from a git repo that modify a Blade file. In the same bash script, run php artisan view:cache.
• Use Illuminate\Filesystem\Filesystem::lastModified to check the timestamp of the modified Blade file and compare it to the timestamp of any compiled view. You will see they are the same.

[ismaildasci]

Hey there! 👋

This is an interesting observation, and it comes up sometimes in automated deployment workflows. The reason Laravel uses >= instead of > for checking if a view is expired is to avoid unnecessary recompilation in typical workflows. However, in cases like yours where a deployment script can lead to identical timestamps, this behavior can cause unexpected results.
Possible Workarounds:

Touch the Blade Files After Pulling Changes:
    You could add a touch command in your deployment script to slightly modify the timestamp of the Blade files after pulling changes. This way, the Blade files will always have a newer timestamp than the compiled views. For example:

    bash

    git pull
    touch resources/views/*.blade.php
    php artisan view:cache

    This ensures that Laravel’s >= comparison works as expected, and compiled views are used correctly.

Consider a Custom Solution:
    If this issue persists, you could customize the view caching process by extending Laravel's Compiler class to use > instead of >=. This approach would require a bit more work but could be helpful if you have specific requirements that the default implementation doesn't meet.

Avoid Caching in Development:
    In development or staging environments, you might skip view caching entirely, as the performance benefit is mainly noticeable in production.

I hope one of these solutions works for you! Let me know if you need any more help with this. 😊

[jlswanson28694]

Your response sounds oddly like ChatGPT...

My deployment script shouldn't be atypical. The Laravel documentation says: "When deploying your application to production, you should make sure that you run the view:cache Artisan command during your deployment process."

Your touch workaround wouldn't get me anywhere, the timestamps would still end up identical. Plus, I don't want the Blade files to have a newer timestamp than the compiled views, I want the opposite.

I ended up adding a small delay using sleep in my bash script before running view:cache to ensure the compiled views have a newer timestamp than the Blade files, but it strikes me as strange that this would be necessary.

[adel007gh]

Hi everyone,

I have a suggestion for adding a new configuration option called USE_STRICT_VIEW_CACHE_COMPARISON to solve this issue. Implementing this feature wouldn't be difficult for me and would probably take about an hour. I believe it could completely resolve the problem you're facing.

Initially, I considered simply changing >= to >, but that approach had its own set of complications.

If you have any other ideas or thoughts, I'd be more than happy to hear them and collaborate further!

I haven't participated in open source projects before, and I think this could be a great starting point for me.

[jlswanson28694]

Hi @adel007gh, I'd be interested to hear the set of complications that come from changing >= to >. I might be missing something.

The only issue with > that comes to mind is if a user runs view:cache right before a different user runs git pull (without running view:cache after), and they happen to finish at the exact same time. This would result in the application serving cached views from the previous commit. This situation seems extremely unlikely, and considering the Laravel documentation instructs running view:cache as part of the deployment process, I don't see it as a strong argument for >= to be the default behavior.

[adel007gh]

Thanks @jlswanson28694
for your input and the thoughtful analysis! Your example highlights an edge case that’s definitely worth considering. Changing from >= to > can indeed have a few implications, even if they seem rare:

Concurrency Issues: As you pointed out, if two processes are running concurrently (e.g., one executing view:cache while another pulls changes from Git), there is a possibility, however minimal, that the compiled view could be out of sync. This could potentially serve outdated views if one step completes just before the other updates the source.

Clock Precision: Another subtle issue involves the precision of timestamps. If the system’s clock or the file system’s granularity for timestamps is not accurate to the second or is slightly off, it could lead to unexpected results where > might not trigger a recompilation when it should.

Compatibility and User Expectations: Changing to > might break the expectations for users relying on the current behavior (>=). For example, automated deployments that don’t always use view:cache might unintentionally serve outdated views without explicit recompilation steps.

Custom Use Cases: Some users might have custom workflows or scripts that expect >= behavior, where any modification time matching the compiled view time still considers it valid.

I believe adding an option like USE_STRICT_VIEW_CACHE_COMPARISON could indeed offer flexibility, allowing developers to choose the behavior that suits their deployment needs. I’d love to hear if you or others have any additional thoughts or scenarios that could help refine this idea.

[jlswanson28694]

This is another ChatGPT answer, and I'm still not convinced > would break anyone's deployment process. Users should follow the Laravel documentation and run view:cache after deployment. All of the possible issues you stated would be resolved by doing so.

Adding a new config option to toggle this behavior seems like overkill in my opinion. I'd change >= to > and see if they have any qualms with the pull request.

[crynobone]

You should just do php artisan view:clear and then php artisan view:cache here. While you can submit a PR it has very small chance of getting approval due to risk of breaking other applications.

[jlswanson28694]

My bash script does run those commands. I clear the cached views before I run git pull, then cache the views again afterwards. As I explained in the original post, the commands run in such quick succession that the Blade file and its associated compiled view have the same modified timestamp, and the view is recompiled unnecessarily. That's why I needed to add a manual delay in the script before caching the views.

As far as I can tell, changing >= to > would have a very minimal risk of breaking other applications. The chance of a Blade file having the same modified timestamp as a cached view from a previous commit would be rare, and would only affect users that don't use view:cache in their deployment process.

Another option could be to adjust the Filesystem lastModified method shown here to return a file modification timestamp with microsecond precision, as discussed here: https://stackoverflow.com/questions/2923844/php-file-modification-time-in-milliseconds.