Fix: DatabaseQueue restores its read/write abilities when an async read-only database access is cancelled.

[groue]

This pull request fixes the bug reported in #1715. Thank you @rcarver!

[rcarver]

Confirming this works in the app, thank you @groue!

[groue]

Confirming this works in the app, thank you @groue!

Thanks for the confirmation 👍

May I ask how you have noticed the bug in the first place, @rcarver? I'm very glad you did, but the bug is only present with DatabaseQueue, I was wondering why an app would use it instead of a DatabasePool (DatabaseQueue is not a mistake, it's just a missed opportunity of using a pool). If you have a few minutes, would you please explain your setup and how the bug was triggered?

[rcarver]

@groue of course! Lucky combination of factors I guess :)

I'm building a new app using the experimental GRDB in Sharing which uses ValueObservation to keep state synced. The app is using TCA which makes use of cancellation when dismissing child features. Finally, since the app is brand new I haven't yet explored DB Pool vs Queue, though it does seem like it will move to Pool when I get to it.

Attached is a simple app that recreates the problem, which I believe is:

• A child feature that observes a single record is added to a list
• The child starts deleting itself
• The parent observes the change and updates state to remove the child
• By removing the child, its in-flight effects are cancelled, which throws the CancellationError
• The child deletion effect receives CancellationError and leaves the db in readonly mode

GRDB Cancellation.zip

FWIW we found that the issue can also be solved by:

• Using the sync version of write
• Wrapping the async write in an Task such that it is not cancelled when the child is dismissed

[groue]

Oh, thank you. I'll just remind that DatabaseQueue serializes all database accesses, when DatabasePool can run parallel reads and writes. With a pool, the read-only parts of an app can run without blocking or any delay, even if some other component of the app performs a (slow) background write. I don't have the slightest idea whether Sharing and TCA support such parallelization.

Anyway, yes we've been lucky :-)

FWIW we found that the issue can also be solved by:

• Using the sync version of write
• Wrapping the async write in an Task such that it is not cancelled when the child is dismissed

Yes. GRDB only honors Task cancellation from its async database access methods (try await read, try await write). Task cancellation is ignored from synchronous accesses. And spawning a new Task is a way to avoid inheriting the cancellation of the parent task.

Happy GRDB!

[groue]

Since I discovered an SQLite bug on the way: I reported it here: Bug report: PRAGMA query_only has side effect when compiled, not when executed.