Rebuild the framework caches in the background after an update - #190
Merged
Merged
Conversation
`optimize` empties the compiled-views directory through view:cache before recompiling, which a request served in the meantime can trip over. The new command runs `optimize --except=views` and then compiles every Blade template in place through CompileViewsAction: Blade writes each compiled file with an atomic rename and skips unchanged output, so the live directory is never cleared. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RqwYa86be82YSKkJYb9VLz
After a version change the optimize used to run synchronously before the PHP server spawned and held the launch for about 1.7 s. The server now starts right away and rfa:optimize runs as a background child with the config, route, and event cache paths pointed at a staging directory. The three files are renamed into place once the child exits cleanly, so no request ever requires a torn cache file. Caches left by the previous version are removed before the server spawns, the child is killed with the app, and the optimized version is stamped only after the rename. The previous synchronous block is upgraded in place, and the launch timeline marks for the optimize move into the background runner. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RqwYa86be82YSKkJYb9VLz
The optimize finish mark now lands after the window presents, so the flush holds for it until the 60 s deadline. The report gains a phase for the background rebuild. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RqwYa86be82YSKkJYb9VLz
Blade and Livewire keep a compiled file while it is newer than its source, and a build's sources predate whatever the previous version compiled. rfa:optimize never clears the live directory, so a stale view survived an update until something recompiled it. The main process now empties storage/framework/views before the server spawns whenever the app version changed. The in-place upgrade from the synchronous optimize block goes with it: the runner now patches from a stored stock copy. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RqwYa86be82YSKkJYb9VLz
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Warning Review limit reachedNext included review available in 1 minute. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (10)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Item 1 of the ranked list in #183. After a version change NativePHP ran
php artisan optimizesynchronously before spawning the PHP server, which held the post-update launch for about 1.7 s while every Blade view recompiled and the config, route, and event caches were rebuilt. The same-version launch was already unaffected (the version gate from #182); this PR takes the cost off the post-update launch too.What
rfa:optimize(new artisan command,CompileViewsAction): runsoptimize --except=views, then compiles every Blade template in place. Plainoptimizeempties the compiled-views directory throughview:cachefirst, which a request served in the meantime can trip over. Blade writes each compiled file through an atomic rename and skips unchanged output, so compiling without clearing is safe next to a serving process.config.php,routes-v7.php, andevents.phpwith a plainfile_put_contentsand the serverrequires them on every request, so the child gets those three paths pointed at a staging directory. They are renamed into place, one atomic rename each, after a clean exit.optimized_versionis stamped only once the caches are in place. A launch that quits early redoes the rebuild next time; the staging directory is wiped on entry.Measured on this branch (local build, forced post-update state)
Post-update launches now present in the same band as warm ones. Before, the same state presented at about 3.1 s on a warm binary (1.7 s of blocking optimize on top of the 1.4 s warm launch). After each post-update launch the three cache files were in place, the staging directory gone, the version stamped, and the log free of errors.
Related
🤖 Generated with Claude Code
https://claude.ai/code/session_01RqwYa86be82YSKkJYb9VLz