CLI: Lock language pack setup#3492
Open
chubes4 wants to merge 1 commit into
Open
Conversation
Collaborator
📊 Performance Test ResultsComparing 07b5409 vs trunk app-size
site-editor
site-startup
Results are median values from multiple test runs. Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff) |
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
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.
Related issues
Proposed Changes
Concurrent CLI invocations can all run
setupServerFiles()and refresh~/.studio/server-files/language-packsat the same time. When one process removes the shared target tree while another is copying or preserving timestamps, the losing process prints transientENOENTsetup warnings even though the requested WP-CLI command completes.This PR serializes the language-pack refresh with Studio's existing lockfile helper, and reruns the size/mtime comparison inside the lock so only the first process refreshes the cache while later processes skip once the cache is current.
Evidence
Reproduction used a disposable
DEV_CONFIG_DIRwith a stale language-pack cache, then ran 24 concurrentstudio wp --studio-no-path cli versionrequests.Before this fix, the repro produced multiple setup warnings while still completing WP-CLI:
I also forced target deletion during copy and reproduced the narrower
utimevariant:After this fix, the same concurrent stale-cache repro against the patched built CLI completed cleanly:
Testing Instructions
npm run cli:buildnpm test -- apps/cli/lib/dependency-management/tests/setup.test.tsnpx eslint apps/cli/lib/dependency-management/setup.tsnode apps/cli/dist/cli/main.mjs wp --studio-no-path cli versionand verify there are noFailed to set up dependency language packswarnings.AI assistance