Studio: site shows offline after import - #4106
Conversation
📊 Performance Test ResultsComparing 621aa15 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) |
bcotrim
left a comment
There was a problem hiding this comment.
Thanks for fix, LGTM 👍
One suggestion: I would move the updateSiteLatestCliPid inside the startWordPressServer. It's a small refactor, but it would ensure we would never run into this issue again.
What do you think?
gcsecsey
left a comment
There was a problem hiding this comment.
I also ran into this issue recently and this solution LGTM.
|
I'm working on E2E tests that will verify this fix too, so I'd like to proceed with landing this. @bcotrim I think the refactor you suggested makes sense, I looked into implementing it, and pushed it as a single commit for now, let me know what you think. |
|
LGTM @gcsecsey 👍 |
|
Thanks for making the adjustments @gcsecsey - I will go ahead and merge this now 👍 |
## Related issues - Related to STU-1870 - The running-site case is the regression test for STU-1982 / #4106 ## How AI was used in this PR Claude Code planned and implemented the suite under my direction. The running-site case caught the STU-1982 bug independently before we found the existing issue and fix. I reviewed the result. ## Proposed Changes Import coverage currently lives only in the Playwright desktop suite, which the migrate-E2E-to-CLI project is moving away from. This PR adds real end-to-end CLI coverage using the minimal in-repo fixtures from #4151 (generated from the "MyPet" demo site): - Each supported backup format is imported into a freshly created site via the built CLI. Each case asserts the import exists cleanly, the backup's custom theme lands on disk, the SQLite database is created, and the imported content is really served (`wp option get blogname` → `MyPet`) against a stopped site, exercising the in-process PHP-WASM path. - The running-site case verifies that importing into a running site stops it and restores it to running afterward. This is the symptom of STU-1982 (`site list` reporting Offline after import), now guarded against regression. - It also fixes a dev-machine-only gap in the shared e2e harness: `runCli` didn't isolate the legacy Electron appdata lookup, so the `00-check-studio-compatibility` migration could find a developer's real pre-split `appdata-v1.json` and abort the CLI — passing in CI (clean machines), failing locally. The same fix rides the STU-1871 blueprint-tests branch; whichever merges second drops its copy in a trivial merge. The new tests are tagged `e2e`: they're skipped in the per-PR unit job (which doesn't build the CLI), so they add zero per-PR CI cost, and run in the manual "CLI E2E Tests" Buildkite job alongside the other migrated suites. ## Testing Instructions 1. `npm run cli:build` 2. `npm test -- apps/cli/commands/tests/import.e2e.test.ts` 3. Optionally run the whole slow suite: `npm test -- --tagsFilter='e2e' --no-file-parallelism` ## Pre-merge Checklist - [ ] Have you checked for TypeScript, React or other console errors? --------- Co-authored-by: Rahul Gavande <rahul.gavande@automattic.com>
Related issues
Fixes STU-1982
How AI was used in this PR
It was used to identify the best approach to use.
Proposed Changes
This PR ensures that the site that was previously started remains started after either import or pull processes complete.
Testing Instructions
npm run cli:buildnode apps/cli/dist/cli/main.mjs import <backup.tar.gz> --path ~/Studio/test-status(replace the backup link with your own backup)node apps/cli/dist/cli/main.mjs site listPre-merge Checklist