Bugzilla

(In reply to Shane Caraveo (:mixedpuppy) from comment #11)
> 1. full migration is the only success
> 2. we want to fallback to kinto in readonly mode (actual server sync not necessary) if there is a failure

I don't really object to this, but this is likely to create scenarios where the user forever has a broken storage.sync implementation - eg, if the source database is corrupt. On the other hand, I guess they already are broken, although we might be making their browser experience worse (eg, trying to migrate every single time storage.sync is used.)

You'll probably also want a path to remove the kinto implementation at some point? It doesn't seem in anyone's interest that we forever keep kinto around just to handle this scenario.

OTOH though, it seems possible this scenario is already experienced by the user for which migration might fail? Eg, if the database is corrupt for the file system is full, then we will fail to set information about these containers in the first place, so the extension will later find them missing and make the same erroneous decision?

> 3. user switching the pref off/on needs to be handled somehow

I think the only way forward is to explicitly not support that. If you allow that, then a variation of your scenario remains possible - eg, "user adds container to new impl, user switches back to old impl, new container now assumed to be deleted". One way to not support this is to swap the pref out for a check of the file-system, and have migration delete the old database on success.

(In reply to Shane Caraveo (:mixedpuppy) from comment #11)
> 1. full migration is the only success
> 2. we want to fallback to kinto in readonly mode (actual server sync not necessary) if there is a failure

I don't really object to this, but this is likely to create scenarios where the user forever has a broken storage.sync implementation - eg, if the source database is corrupt. On the other hand, I guess they already are broken, although we might be making their browser experience worse (eg, trying to migrate every single time storage.sync is used.)

You'll probably also want a path to remove the kinto implementation at some point? It doesn't seem in anyone's interest that we forever keep kinto around just to handle this scenario.

OTOH though, it seems possible this scenario is already experienced by the user for which migration might fail? Eg, if the database is corrupt or the file system is full, then we will fail to set information about these containers in the first place, so the extension will later find them missing and make the same erroneous decision?

> 3. user switching the pref off/on needs to be handled somehow

I think the only way forward is to explicitly not support that. If you allow that, then a variation of your scenario remains possible - eg, "user adds container to new impl, user switches back to old impl, new container now assumed to be deleted". One way to not support this is to swap the pref out for a check of the file-system, and have migration delete the old database on success.