Migrated from ISSUES.md, which was retired in favour of GitHub issues. Original id I155, priority P2, from the 2026-07-02 deep review (docs/reviews/review-20260702-001902.md).
The text below is the triaged entry verbatim, including the corrections triage made to the original finding.
Where: python/src/transaction.rs:135
Problem: PyTransaction's data operations (allocate, read, update, delete, delete_many, allocate_tagged, set_root_name, savepoint, etc., lines 135–227) do not check the finished guard; only commit()/rollback()/exit do. A finished Transaction object still forwards every operation to the db. After t1 = db.transaction(); t1.commit(); t2 = db.transaction(), a stray t1.allocate(b"x") silently writes into t2's transaction — the exact 'called the wrong object' bug class that the I22/I24 AlreadyFinishedError guard was added to surface, applied to commit/rollback but not to the data ops. If no new transaction is active the engine at least raises NoActiveTransactionError, but the aliasing case is silent data misattribution.
Direction of fix: Check finished at the top of each forwarding method and raise AlreadyFinishedError, consistent with the commit/rollback policy.
Migrated from
ISSUES.md, which was retired in favour of GitHub issues. Original id I155, priority P2, from the 2026-07-02 deep review (docs/reviews/review-20260702-001902.md).The text below is the triaged entry verbatim, including the corrections triage made to the original finding.
Where:
python/src/transaction.rs:135Problem: PyTransaction's data operations (allocate, read, update, delete, delete_many, allocate_tagged, set_root_name, savepoint, etc., lines 135–227) do not check the
finishedguard; only commit()/rollback()/exit do. A finished Transaction object still forwards every operation to the db. Aftert1 = db.transaction(); t1.commit(); t2 = db.transaction(), a strayt1.allocate(b"x")silently writes into t2's transaction — the exact 'called the wrong object' bug class that the I22/I24 AlreadyFinishedError guard was added to surface, applied to commit/rollback but not to the data ops. If no new transaction is active the engine at least raises NoActiveTransactionError, but the aliasing case is silent data misattribution.Direction of fix: Check
finishedat the top of each forwarding method and raise AlreadyFinishedError, consistent with the commit/rollback policy.