[Website] Delay .zip Playground imports until OPFS sync is finished by ashfame · Pull Request #3847 · WordPress/wordpress-playground

ashfame · 2026-06-30T18:11:41Z

What it does

Before this PR, importing a Playground .zip could start while the newly-created saved Playground was still autosaving to OPFS.

After this PR, the import waits until OPFS sync finishes. This avoids modifying MEMFS file handles that are already targeted for OPFS synchronization.

Rationale

Importing a .zip file to restore a previous Playground was failing when started while the initial autosave was still running.

Testing instructions

Create a Playground
Download it as a zip file
Close the Playground browser tab and reopen it
Import the downloaded zip file
Confirm the zip imports cleanly

brandonpayton · 2026-06-30T20:19:05Z

 			}
 		};
 		doImport();
-	}, [pendingZipFile, pendingZipTargetSlug, activeSite, playground, onClose]);


I wonder if there is a deeper cause we ought to be fixing here. We are already using a useEffect() hook to avoid duplicating import activity.

Why isn't it working? What is now changing to restart the import?

I'm finding that the onClose handler keeps changing. If I remove that, from the effect dependency list, the apparent problem disappears and, from a user perspective, the import appears to succeed.

It seems like we we shouldn't base our effect on the value of a provided onClose prop, but I bet there is a reason it was added.

One thing to note:
Even though the import appears to succeed after removing onClose from the effect deps, there is the following error. I'm not sure yet whether it is related to removing onClose or another issue.

Error syncing saved Playground to OPFS NotFoundError: A requested file or directory could not be found at the time an operation was processed. at newError (serialize-error.ts:115:5) at Module.deserializeError (serialize-error.ts:274:8) at Object.deserialize (api.ts:657:34) at fromWireValue (comlink-sync.ts:958:45) at async Object.mountOpfs (boot-playground-remote.ts:393:11)Caused by: Error: Comlink method call failed at Object.deserialize (api.ts:668:32) at fromWireValue (comlink-sync.ts:958:45) at async Object.mountOpfs (boot-playground-remote.ts:393:11)Caused by: Error: Comlink method call failed at Object.deserialize (api.ts:668:32) at fromWireValue (comlink-sync.ts:958:45) at async syncInitialOpfsFilesInBackground (boot-site-client.ts:423:3)

To clarify, just removing onClose from the dependency list on trunk, without this PR, seems to stop the duplicate importing.

Codex suggested that Autosaving new Playgrounds causes this problem, sounds somewhat plausible:

The failure is a race in the browser “Import .zip” flow:

Import creates a new OPFS saved site.

That new site first boots in MEMFS, then copies initial WordPress files to OPFS in the background.

The import can start mutating /wordpress while that initial OPFS copy is still running.

This can leave the site showing “Save failed” or persisted with stale/missing files.

The OPFS NotFoundError doesn't happen with this PR's changes, but it happens when I just remove the onClose dependency from the import effect.

The failure is a race in the browser “Import .zip” flow:

That appears to be the case. Importing a zip calls createSiteForImport().

wordpress-playground/packages/playground/website/src/components/saved-playgrounds-overlay/index.tsx

Lines 184 to 192 in ad08dec

const handleImportZip = async (e: React.ChangeEvent<HTMLInputElement>) => {

const file = e.target.files?.[0];

if (!file) return;

try {

const targetSlug = await createSiteForImport();

setPendingZipTargetSlug(targetSlug);

setPendingZipFile(file);

} catch (error) {

And createSiteForImport() is creates a new OPFS-backed site:

wordpress-playground/packages/playground/website/src/components/saved-playgrounds-overlay/index.tsx

Lines 165 to 175 in ad08dec

/**

* Creates or selects a target Playground before importing a zip archive.

*

* Imports prefer a new OPFS-backed site so the result survives a refresh.

* If that cannot be created, the import falls back to an existing or new

* temporary site.

*/

async function createSiteForImport() {

try {

return await sitesAPI.createNewSavedSite();

} catch {

I believe this PR doesn't experience the OPFS NotFoundError because it delays the import while activeOpfsSyncStatus is "syncing". I think that is probably the right call. We could be even more explicit about setting an "importing" state or about a new site being completely ready for use, but I think this PR's current approach is a reasonable touch and maybe the right depth for now.

note: I edited the above comment to make more sense.

@brandonpayton I don't like when Codex amends commits, otherwise you could have seen the iterations that you went through yourself :) I will do a follow up PR today addressing your feedback.

brandonpayton

Thanks for working on this fix, @ashfame. It is testing well for me using the original failed import zip and an import zip I created locally.

I think this is the right touch for such a fix. Nice job!

I left one review suggestion that would be cool to address. Overall, I think this is good to go.

brandonpayton · 2026-07-01T01:39:28Z

-					wordPressFilesZip: pendingZipFile,
+					wordPressFilesZip: zipFile,
 				});
+				await flushImportedWordPressFiles(playground);


It would be helpful to add an inline comment about why we are flushing, since we were not flushing before this PR.

It seems like a reasonable thing to do though.

brandonpayton · 2026-07-01T01:46:31Z

@ashfame, I forgot to mention as part of the review:
It would be great to add an E2E test for this, but it could be done as a follow up PR.

## What changed - Add an inline comment explaining why ZIP imports explicitly flush OPFS before reporting success. - Add Chromium E2E coverage for imported saved-site durability. ## E2E test coverage 1. Creates a temporary Playground with a known marker and saves it to OPFS. 2. Imports a generated ZIP containing a distinct marker into a new saved Playground. 3. Waits for exactly one success alert and resolves the imported site slug. 4. Immediately fresh-boots the imported slug from `?site-slug=<slug>`, discarding the runtime that performed the import. 5. Requests the imported marker from the fresh runtime and confirms that it was restored from saved storage. 6. Verifies that no “Save failed” or “Site failed” UI appears. 7. Switches to the original saved site, then back to the imported site, and verifies that the marker still loads. 8. Direct-loads the imported slug once more and verifies that the marker remains available. ## Why The previous assertion order requested the imported marker from the active import runtime before switching sites. Completing that request emits `request.end`, which can trigger background OPFS flushing and mask files that were not durable when import success was reported. Fresh-booting first checks the user-visible contract: once import reports success, the imported files can be restored from saved storage. This intentionally remains a black-box durability check; it does not couple the test to Comlink or assert which OPFS flush path completed. Follow-up to review feedback on #3847. --------- Co-authored-by: Brandon Payton <brandon@happycode.net>

github-actions Bot added [Package][@wp-playground] Blueprints [Package][@wp-playground] Website [Aspect] Browser [Aspect] Website labels Jun 30, 2026

ashfame force-pushed the codex/fix-concurrent-zip-import branch from 3de7988 to 50bc8ee Compare June 30, 2026 18:45

ashfame changed the title ~~[codex] Fix concurrent Playground zip imports~~ Jun 30, 2026

ashfame mentioned this pull request Jun 30, 2026

[Blueprints] Make WordPress file imports failure-safe #3848

Merged

Prevent duplicate zip imports

93a0e7f

ashfame force-pushed the codex/fix-concurrent-zip-import branch from 50bc8ee to 93a0e7f Compare June 30, 2026 19:09

ashfame marked this pull request as ready for review June 30, 2026 19:58

ashfame requested review from a team and zaerl June 30, 2026 19:58

brandonpayton reviewed Jun 30, 2026

View reviewed changes

brandonpayton approved these changes Jul 1, 2026

View reviewed changes

adamziel changed the title ~~[codex] Prevent duplicate Playground zip imports~~ Jul 1, 2026

adamziel merged commit 7577913 into trunk Jul 1, 2026
55 checks passed

adamziel deleted the codex/fix-concurrent-zip-import branch July 1, 2026 10:14

ashfame mentioned this pull request Jul 2, 2026

[Website] Add E2E coverage for playground-zip import regressions #3874

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[Website] Delay .zip Playground imports until OPFS sync is finished - #3847

[Website] Delay .zip Playground imports until OPFS sync is finished#3847
adamziel merged 1 commit into
trunkfrom
codex/fix-concurrent-zip-import

ashfame commented Jun 30, 2026 •

edited by adamziel

Loading

brandonpayton Jun 30, 2026

brandonpayton Jun 30, 2026

brandonpayton Jun 30, 2026

adamziel Jun 30, 2026

brandonpayton Jul 1, 2026 •

edited

Loading

brandonpayton Jul 1, 2026

ashfame Jul 1, 2026

brandonpayton left a comment

brandonpayton Jul 1, 2026

brandonpayton commented Jul 1, 2026

Uh oh!

Labels

3 participants

	const handleImportZip = async (e: React.ChangeEvent<HTMLInputElement>) => {
	const file = e.target.files?.[0];
	if (!file) return;

	try {
	const targetSlug = await createSiteForImport();
	setPendingZipTargetSlug(targetSlug);
	setPendingZipFile(file);
	} catch (error) {

	/**
	* Creates or selects a target Playground before importing a zip archive.
	*
	* Imports prefer a new OPFS-backed site so the result survives a refresh.
	* If that cannot be created, the import falls back to an existing or new
	* temporary site.
	*/
	async function createSiteForImport() {
	try {
	return await sitesAPI.createNewSavedSite();
	} catch {

Uh oh!

Conversation

ashfame commented Jun 30, 2026 • edited by adamziel Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What it does

Rationale

Testing instructions

brandonpayton Jun 30, 2026

Choose a reason for hiding this comment

brandonpayton Jun 30, 2026

Choose a reason for hiding this comment

brandonpayton Jun 30, 2026

Choose a reason for hiding this comment

adamziel Jun 30, 2026

Choose a reason for hiding this comment

brandonpayton Jul 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

brandonpayton Jul 1, 2026

Choose a reason for hiding this comment

ashfame Jul 1, 2026

Choose a reason for hiding this comment

brandonpayton left a comment

Choose a reason for hiding this comment

brandonpayton Jul 1, 2026

Choose a reason for hiding this comment

brandonpayton commented Jul 1, 2026

Uh oh!

Labels

3 participants

ashfame commented Jun 30, 2026 •

edited by adamziel

Loading

brandonpayton Jul 1, 2026 •

edited

Loading