SQLITE_BUSY on iOS

[link2xt]

Delta Chat for iOS is running chatmail core in two separate processes. When they both try to process the notification and fetch messages at the same time, this results in a device message ❌ Failed to receive a message: add_parts error: database is locked: Error code 5: The database file is locked. Please report this bug to delta@merlinux.eu or https://support.delta.chat/. The error is not new, but since #7401 it is visible. Previously it likely resulted in receive_imf trying to write a partial download message, which itself may fail, and before partial download for failed messages was introduced the message was silently dropped.

Normally if only one core is running it is not possible to get such error because we have in-process lock inside the connection pool that only allows one writer, but on iOS two processes open the database at once and write independently. On all other platforms accounts.toml file is locked so it should not be even possible to run two processes with the same accounts folder, but on iOS the main process is running together with the notification extension:

core/src/accounts.rs

Lines 555 to 561 in a5c470f

	#[cfg(target_os = "ios")]
	async fn create_lock_task(_dir: PathBuf) -> Result<Option<JoinHandle<anyhow::Result<()>>>> {
	// Do not lock accounts.toml on iOS.
	// This results in 0xdead10cc crashes on suspend.
	// iOS itself ensures that multiple instances of Delta Chat are not running.
	Ok(None)
	}

As a workaround we can enable default busy handler for iOS. This will not solve the problem completely, but will make it less likely that users see this error.

This can be enabled either with PRAGMA busy_timeout or busy_timeout() function. Function seems to be preferred according to the documentation. We only need to do this on the write connection.

[iequidoo]

As a workaround we can enable default busy handler for iOS. This will not solve the problem completely, but will make it less likely that users see this error.

I think this busy_timeout should just be set to the maximum value because it's not a normal thing that we can't write. Better if the user needs to kill the app forcibly than there will be a missing message or other irreversible db change, the device message isn't really helpful.

[link2xt]

I have created #7471 with a 1 minute timeout. It is not the maximum value, but is really large, if we cannot write to the database for one minute it is likely deadlocked. We use 1 minute timeouts for network connections everywhere as well.