Fix stale OPFS exports after pooled PHP requests - #4240
Draft
ashfame wants to merge 4 commits into
Draft
Conversation
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.
What
Fix saved-site ZIP exports that could omit recent writes made by a pooled PHP instance.
This PR deliberately preserves the investigation sequence in separate commits: regression coverage first, the request-end trigger fix second, and the OPFS export durability barrier third.
Root cause
Secondary PHP instances write through PROXYFS into the primary PHP instance MEMFS, so the primary OPFS journal captures their file operations. However,
request.endis emitted on the secondary PHP instance while the mounted journal listens on the primary instance. A pooled request could therefore finish with captured operations still queued in memory, and direct saved-site export would traverse stale OPFS contents. Explicit saving only appeared to repair the archive because another lifecycle operation happened to trigger the pending flush.Direct export also lacked an awaited boundary around asynchronous journal replay. Even with the missing trigger fixed, a ZIP traversal could race a flush that had already been scheduled.
Commit and CI sequence
eba38e26dadded the pooled-PHP browser regression, andb4e0945a6corrected its marker path to a guaranteed existing directory. The corrected regression proves the marker exists in live MEMFS but remains absent from OPFS: expected CI failure.4aa613f5aflushes every active OPFS journal when a secondary PHP request ends. The same Chromium shard then passes: trigger-fix CI success.384574945adds a per-site, origin-wide Web Locks boundary. Journal replay holds an exclusive lock; direct ZIP export holds the matching shared lock, so export waits for earlier writes and traverses a stable snapshot. The actual OPFS directory path identifies the lock, including legacy saved-site directories.Tests
npm exec -- nx run-many -t typecheck -p php-wasm-web playground-remote playground-website --parallel=3npm exec -- nx run-many -t test -p php-wasm-web playground-remote playground-website --parallel=3(468 tests)npm exec -- nx run-many -t lint -p php-wasm-web playground-remote playground-website --parallel=3