PLAT-73 Serialize environment updates to prevent race conditions #279
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.
Desktop fix (for PR description)
Problem
FsManager.updateEnvironment(id, patch)can be invoked concurrently for the same environment (e.g. rename fired twice quickly, or multiple UI surfaces triggering updates close together).fs.rename(oldPath, newPath).oldPathviafileIndex.getPath(id)fs.rename(oldPath, newPathX)oldPathand throwsENOENTFix
requestly-desktop-appso updates for the same entity are serialized.src/renderer/actions/local-sync/fs-manager.tsupdateLocks: Map<string, Promise<unknown>>withUpdateLock(key, fn)helper that:FsManager.updateEnvironment()body inwithUpdateLock(lockKey, async () => { ...existing logic... })${this.rootPath}::env::${id}so:Why this is safe
oldPath, eliminating theENOENTrace.Result
ENOENT, because the filesystem rename andfileIndexupdates happen in a deterministic sequence.Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.