Description
Specification
Previously the destroy call was called inside commit and rollback. This has since been removed since #53, since the ResourceAcquire<DBTransaction> already called destroy and it was unnecessary to call destroy twice.
However we discovered in the EFS (MatrixAI/js-encryptedfs#74 (comment)), a dangling/floating promise could still have a reference to the transaction and end up trying to do a get on a transaction that is already committed. This ends up with the C++ code throwing a TRANSACTION_COMMITTED exception. This is not caught on the JS side because it was not expected to happen.
We are relying on the @ready decorator to protect the get methods and other methods if they are called when the transaction is already destroyed. But it does appear that there can be time between commit/rollback and destruction because these are separate functions.
We could make commit/rollback the equivalent of a destruction by applying the commit/rollback code inside the destroy call. And make destroy have a type: 'commit' | 'rollback' union. This way DBTransaction.commit and DBTransaction.rollback is just forwarding the call to the destroy.
This can simplify our transaction lifecycle, and ensure that methods cannot be called when a commit/destroy is being called, because this means it's in the process of being destroyed. It could also mean that we can use the ready blocking that we found we couldn't do when attempting to fix the dangling transactions during db.stop().
Additional context
- Fix committing or rollbacking dangling transactions #53 - waiting for commit/rollback when
db.stop()is destroying dangling transactions - ci: merge staging to master js-encryptedfs#74 (comment) - bug involving a dangling transaction operation
Tasks
- ...
- ...
- ...