[tmgbedu]

Summary

• Before this change, a raising after_commit callback stopped the loop, so the remaining callbacks were skipped even though the write was already committed.
• Now every queued callback runs (sync, async or returning an awaitable). After the last one, the first exception is re-raised unchanged with its original traceback. It surfaces from commit_transaction, Transaction.commit() or async with connection.transaction().
• Any later failures are logged with their traceback on the fastapi_startkit.masoniteorm logger, so they aren't lost.
• BaseExceptions such as CancelledError still propagate immediately.
• The commit stays durable, and the connection goes back to the pool before callbacks run.
• Not changed: outside a transaction, a callback runs immediately and raises directly. Callbacks still merge up from savepoints and are discarded on rollback.
• There is no reporter hook and no log-and-continue mode. ADR 057 records why, and why an ExceptionGroup was rejected.

Docs follow-up

The Database Transactions section of docs/database/index.md in the docs repo says errors propagate after a durable commit. That is still true. It should add that the remaining callbacks still run and only the first error is raised.

Test plan

• Updated tests in tests/masoniteorm/connections/test_after_commit.py:
  • first callback raises: the later sync and async callbacks still run, then the error is raised (manual, context and object commits);
  • the row stays committed and nothing is left checked out on a pool_size=1 engine;
  • with two failures, the first is raised and the second is logged;
  • a failing callback in a savepoint raises after the outer commit;
  • an immediate failing callback raises;
  • cancellation propagates.
• uv run pytest --ignore=tests/masoniteorm/postgres --cov: 3722 passed, coverage 92.75%.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[tmgbedu]

Closing: stopping at the first failing after-commit callback is the intended behaviour and matches Laravel. DatabaseTransactionRecord::executeCallbacks() is a plain loop with no try/catch, so after the durable commit the first exception propagates to the caller and the remaining callbacks are skipped. Main already does this (covered by test_callback_error_propagates_after_commit_without_queue_leak). Callbacks that must not block the others should handle their own errors or dispatch a queued job.