tangled.org / core
Monorepo for Tangled tangled.org
752
fork

Configure Feed

Select the types of activity you want to include in your feed.

proposal: PDS migration page #203

open opened by boltless.me

Reviving #299 proposal: generalized collection migration UI

Context:#

We need migration for atproto records on user's PDS (e.g. .feed.comment or future org.tangled.* records.) Supporting legacy records forever is unrealistic. We should at least cleanup most of legacy records. But we need active PDS session to perform migration.

Currently we already do some migrations on login, but it requires user action to logout and relogin.

Solution#

  1. schedule migrations for legacy records in appview DB
  2. on any active user session, when there are pending migrations, redirect to /migration page
  3. on /migration page, show real-time migration progress
  4. when migration is done, redirect back to original page

Something like this:

/migration?return_url=/tangled.org/core/issues

Tangled is migrating some legacy data from your [PDS].
You will be redirected back to [/tangled.org/core/issues] when migration completes.

[1/3] Add `RepoDid` field to repo-referencing records

Progress: 30% [=======>             ]

So appview won't require relogin for migration, and users can know what's happening clearly. As this strategy doesn't require relogin, it is more strong, so we can expect legacy records to be migrated more quickly.

When sufficient amounts of records are migrated, we can deprecate backwards-compatibility layer from appview code.

boltless.me (author)

One thing we should decide is behavior on migration failure.

There can be various reasons for a migration to fail:

  • target record does not exist in users PDS
  • target record has unexpected structure (missing field, etc)
  • general appview DB operation failure
  • general PDS xrpc call failure

Option 1#

Expect all migrations to succeed. Always redirect to /migration page when there are pending migrations for that account. This won't let users to use tangled until the bug gets resolved.

Option 2#

Track failed migrations. Don't redirect to /migration page when previous attempt failed. We can just remove the old records from appview DB & restore them once migrating succeed.

From user's perspective, option 1 is pretty tough experience, but if we go with option 2, we can easily have dangling failed migrations...

oyster.cafe

But the migration is somewhat non-blocking, right? the user can also freely navigate away if they want and it won't pause/bork a migration.

Now that we're gonna add more to the pending pds rewrites table, I think this is a nice thing to have instead of waiting for re-login, though I also think that pinging the table in the first place in every session could simply trigger the migration in the background, still no page needed.

boltless.me (author)

The reason I'm thinking of migration page instead of silent background job is because it might require user actions in future.

e.g. "we will truncate your super long repository name"

When performing this kind of breaking change, it would always be nicer to explicitly ask for confirmation (e.g. rename or delete.) Also performing PDS write without explicit user action feels bit... unexpected? can't found a good word. Appview already automatically creates sh.tangled.profile on login, but that requires clear user action: "login".

Not a strong opinion though. I just think it would be better to be transparent about the operation.

sign up or login to add to the discussion
Labels

None yet.

assignee

None yet.

Participants 2
AT URI
at://did:plc:xasnlahkri4ewmbuzly2rlc5/sh.tangled.repo.issue/3miswcn42xh22