"Transaction used after it was closed" - can I request new query executor?

[gospodarp]

Hi! Appreciate the package!

(Tested on android, drift 2.10.0 with isolates enabled)

I am encountering "Transaction used after it was closed" assertion error. What happens is that I launch asynchronous/delayed interaction with DB inside of a transaction. Following pseudo example illustrates the issue:

class SomeDao extends _$SomeDaoMixin {
  Future<void> testTransaction() async {
    await transaction(() async {
      await select(some).get();

      Timer.periodic(Duration(seconds: 10), (_) async {
        // Here select will give the error although it is run after transaction finishes
        // After a bit of digging I made an assumtion that execution context is bound to transaction in some way hence the error
        // (I am quite new to dart so this may be some closure binding I am unaware of)
        await select(some).get();
      });
      
      await Future.delayed(Duration(seconds: 5));
    });

    // Transaction finishes succesfully and after ~5 seconds the error will be thrown (and on all subsequent executions of timer)
  }
}

So the question is:

1. Does this assertion error has any effect in release?
2. Can I rewrite code to do same thing but avoid the error?
3. Can I catch error and create new execution context/query executor?
4. I there something else I am missing/can do?

PS. I know transaction doc says that you have to await all calls, but I didn't think it was that extreme :) Can someone elaborate on whats happening?

Thanks in advance!

[simolus3]

The intended behavior is that, after the transaction block completes, the logical transaction is ending as well. Drift goes quite a length to achieve that (for instance, streams watching a drift query in a transaction will also close their listeners afterwards). We need to do that because transactions need an explicit COMMIT statement, and we can't know that your timer action is read-only (if it weren't, should it implicitly run outside of the transaction? that can lead to some hard-to-debug correctness issues for the more common case where you simply forgot an await). So tldr, everything happening in a transaction block needs to be done accessing the database when it completes.

// (I am quite new to dart so this may be some closure binding I am unaware of)

Indeed, drift uses zones to bind the transaction callback (and all the asynchronous calls that it will make it turn) to the transaction.

To answer your questions,

1. Does this assertion error has any effect in release?

I think your queries would softlock without the assertion. Drift runs the database in another thread (if you're using NativeDatabase.createInBackground), and that thread is responsible for running queries based on which transaction in which thread/isolate is currently active (as sqlite3 can't have more than one transaction per connection). So if you still use a transaction that has been closed, your query would never get scheduled.
As this is a conceptual problem, you also can't create a new transaction from a finished transaction (so something you asked about in 3. is not possible).

2. Can I rewrite code to do same thing but avoid the error?

I think the easiest solution would be to literally move the timer setup outside of the transaction, e.g. by starting the timer before or after the transaction.

4. I there something else I am missing/can do?

This is a bit hacky, but also works if moving the timer outside of the transaction block is not easily possible:

// Call this outside of the transaction to get a callback capable of running code outside
// of the transaction context.
final escapeHatch =
    Zone.current.bindUnaryCallback((void Function() argument) => argument());

await db.transaction(() async {
  await select(some).get();

  escapeHatch(() {
    Timer.periodic(const Duration(seconds: 10), (timer) async {
      await select(some).get();
    });
  });

  await Future.delayed(const Duration(seconds: 5));
});

With this setup, note that queries in the timer can't run if the transaction is still active (so if the transaction takes more than 10 seconds to complete, the first timer query will be delayed).

[gospodarp]

Many thanks for giving me understanding on whats going on with Zones!

I see them mentioned several times in code docs but mb it makes sence to make more emphasis on it in transaction docs for guys like me ^^?

Decided to refactor code to not run async updates inside of a transaction, but really like your "hack".

Marking as resolved. Thanks again!

[simolus3]

Good point, I'll change the documentation to point this out.