Incomplete database not deleted after restore failure

[gerryfrancis]

• Android version:
  Android 11.

• Device:
  Fairphone FP2 (Lineage OS 18.1 build RQ3A.211001.001 from 2022-04-22).

• Delta Chat version:
  1.29.1 (nightly built 2022-04-24).

• Expected behavior:
  During setup: After the database restore process has failed due to insufficient disk space (OS error 28), the incompletely restored database is deleted from the device.

• Actual behavior:
  During setup: After the database restore process has failed due to insufficient disk space (OS error 28), the incompletely restored database is not deleted from the device.

• Steps to reproduce the problem:
  -- Restore a previously backed up database on a device with very low disk space to make the error occur.

• Screenshots:
  N/A.

• Logs:
  N/A.

• Remark:
  I have no clue whether it makes a difference if a database is restored during setup or in "Preferences" in this regard.

[gerryfrancis]

To add: Even though the database has not been restored completely, new emails that were delivered to the Inbox before have been fetched right on, and I can see the notifications for them layed over the welcome screen. (The matter in this case was not too less disk space, of course.)

[link2xt]

This is not fixed yet, moving to the core.

[gerryfrancis]

Even though the database has not been restored completely, new emails that were delivered to the Inbox before have been fetched right on, and I can see the notifications for them layed over the welcome screen.

FYI , this seems to be solved, but the core issue, this one, is still valid.

[link2xt]

So this is still an issue, if backup restore fails, the account with incomplete database is started anyway and user starts receiving notification even thought the backup is broken.

[gerryfrancis]

FYI, I have stumbled over that issue once again just recently.

[link2xt]

@iequidoo I have looked at #5086, but as there are no tests it is not clear if it is an improvement.

A fix for this issue I can imagine is to make account import/export a function of account manager, so account manager can unpack an account and only plug it into accounts.toml once it is complete. Otherwise if account import fails, an imported account folder will remain in accounts folder but can be garbage-collected, e.g. next time accounts.toml is reopened.
But then it is a large change for all the UIs and there is no way to get import events because there is no event-emitting account yet.

So "unconfigured" account probably should stay, but maybe think in terms of importing an account into a separate temporary folder and then replacing old account folder with a new one?

[iequidoo]

@iequidoo I have looked at #5086, but as there are no tests it is not clear if it is an improvement.

A fix for this issue I can imagine is to make account import/export a function of account manager, so account manager can unpack an account and only plug it into accounts.toml once it is complete. Otherwise if account import fails, an imported account folder will remain in accounts folder but can be garbage-collected, e.g. next time accounts.toml is reopened. But then it is a large change for all the UIs and there is no way to get import events because there is no event-emitting account yet.

I also thought in this direction, but it looked complicated to me and i decided just to improve the existing code. Although there are no tests yet (so it may degrade easily), i think that for now it can be useful:

• The account manager is not used everywhere, at least not in deltachat-repl.
• Unpacking all blobs before importing a db looks better, at least all things happen in a well-defined order.

So "unconfigured" account probably should stay, but maybe think in terms of importing an account into a separate temporary folder and then replacing old account folder with a new one?

I could try to implement this as the next step.