Sequelize Nested Transactions: Unclear Rollback Behavior in Deployment Logs

Sequelize nested transaction logs show ambiguous rollback status

When a nested transaction fails, Sequelize logs a "ROLLBACK TO SAVEPOINT" statement. However, the logs do not indicate whether the outer transaction was subsequently aborted or left in a committed state. This ambiguity can lead to partial commits during a deployment, especially when the deployment pipeline ignores intermediate rollback entries.

Key constraints include dialect differences: MySQL and PostgreSQL support native savepoints, while SQLite emulates them with limited support. Isolation levels are inherited by default, and a nested transaction committed before its parent may still be lost if the parent later fails.

Unresolved questions:

• Does a "ROLLBACK TO SAVEPOINT" in the logs guarantee that the outer transaction will be rolled back, or can it still be committed?
• How can deployment pipelines reliably detect whether an outer transaction was aborted after a nested rollback?
• What best‑practice configuration ensures that nested transaction failures do not leave orphaned changes in the database?