fix(migration): resume inbound migration interrupted during blob copy #684

Open

trezy.codes 22h ago

targeting main from trezy.codes/tranquil-pds:fix/migration-resume-blobs-v2

Open opened by and assigned to

trezy.codes 22h ago targeting main from trezy.codes/tranquil-pds:fix/migration-resume-blobs-v2

Found this while migrating an account with ~28k blobs. If you try to reload the migration page after the internet disconnects or the page reloads while blobs are being copied, you'll keep getting forced through OAuth consent for the old PDS, then landing on "Migrate blobs" forever. 🫠

handleOAuthCallback is capable of resuming the email/PLC/finalize steps, but for migrating it just calls setStep() and nothing actually restarts. On top of that, the local session never got saved before email-verify (and rotated tokens weren't saved during long copies), so there was nothing to resume with anyway.

Resuming at migrating now picks the copy back up
Pulled the post-import steps into finishMigration so it works whether you just started the migration or you're restarting after a disconnect
Local session is saved at account creation, so re-auth after refresh should no longer be necessary
No more dead ends. If there's nothing to resume with (import never finished, or state from an older build), you get "Start over" instead of a spinner. The offline flow had the same problem.

Tests cover the resume paths. I also ran it locally against a second PDS with ~300 blobs. I reloaded twice in the middle of the copy, it picked up both times and made it to email verification with everything copied. Same steps on main get stuck.

Commits 0

Could not load commits.

Comments

v0 22h ago

oyster.cafe 10h ago

frontend/src/lib/migration/flow.svelte.ts:349 could you also restore state.passkeySetupToken here/somewhere? and I guess maybe add a test mode like frontend/src/tests/migration/flow-resume.test.ts:58 here for passkey based flow?

oyster.cafe 9h ago

frontend/src/lib/migration/flow.svelte.ts:535 I think this might bork if there's an interruption after creating the account yet before importing, where you'll get told to start over but then that handle's taken etc. what could we do to not lock out that handle? or idk if resuming from there isn't possible, maybe we just say sorry try a new handle

oyster.cafe 9h ago

oh yeah could ya please put the verificationChannel into the StoredMigrationState also while we're here? 😇

v1 6h ago

trezy.codes 6h ago

passkeySetupToken now gets restored on every resume. The resume tests are a describe.each over password and passkey now, so every resume case runs for both.

Now that the local session gets saved as soon as the account exists, a reload between creation and import just picks back up: it re-exports the repo from the old PDS, re-imports it, and carries on with blobs without starting over. importRepo is fine to run again on the deactivated migration account.

I found another thing while testing in the browser: reloading mid-import aborts the request, and its error got saved before the page went away, which clobbered the resume point. Errors raised while the page is unloading are no longer saved. If a migration does end up on the error screen after the account exists, reloading and logging back in resumes it instead of starting over.

If there's no saved session at all, you still get sent to start over, but:

password accounts can use the same handle, since createAccount with service auth reactivates the existing deactivated account (try_reactivate_migration), so no lockout there
passkey accounts don't have that reactivation path yet (create_passkey_account doesn't do it), so the message says to ask the admin to remove the unfinished account if it complains the handle's taken

I also saved the discord/telegram/signal username alongside it, since resending the code needs it after a resume.

v2 5h ago

v3 4h ago

oyster.cafe 4h ago

frontend/src/locales/fi.json:1167 why not? seems correct as far as the ones i understand enough of; idk french

trezy.codes 1h ago

I can put them back if you want. It was Claude escaping containment, and I'm not personally comfortable trusting any output from it if I don't understand it. I don't speak anything other than English, so I pulled it.

Versions