Sequelize事务提交后执行回滚触发“Transaction cannot be rolled back”报错

错误根因 #

• 你遇到的报错本质是设计逻辑和Sequelize的事务实现规则冲突：Sequelize的事务采用单终态设计，只要执行过commit()方法，事务实例的finished属性就会被永久标记为"commit"终态，此时调用rollback()会直接触发内置的状态校验错误，抛出你日志里看到的提示。
• 从数据库底层原理来看，事务提交是不可逆的永久操作：一旦执行commit，所有关联的数据变更就已经持久化到数据库，不存在“提交完成后再通过回滚撤销变更”的可能性，你当前“先提交事务、再抛错触发回滚”的逻辑本身就不符合事务的运行机制。

不同业务场景的正确实现 #

场景1：全链路业务校验通过后统一提交事务 #

这是最贴合你需求的常规事务使用方式：所有业务操作、校验逻辑全部执行完成，没有触发异常/回滚条件时，再执行事务提交；任何环节触发回滚条件，都在提交前抛出错误触发回滚。
示例代码：

let transaction
try {
  // 开启事务
  transaction = await ctx.app.model.transaction();
  // 透传事务到所有业务操作
  const newPageResult = await pageService.add(addPageResult, { transaction });

  // 把回滚判断逻辑、异常抛出放在提交前执行
  // 替换为你实际的业务判断条件
  const shouldRollback = true;
  if (shouldRollback) {
    throw new Error("do rollback");
  }

  // 所有校验通过后再提交事务
  await transaction.commit();
} catch (err) {
  // 先判断事务状态，避免对已提交/未开启的事务执行回滚报错
  if (transaction && transaction.finished !== 'commit') {
    await transaction.rollback();
  }
  // 向上抛出异常，让框架正确识别接口错误状态
  throw err;
}

场景2：需先提交部分操作，后续再触发数据撤销 #

如果业务确实需要先完成一批数据变更落库，后续再触发反向操作，这种场景已经超出单事务的覆盖范围，不能依赖事务的rollback实现，需要自行设计业务补偿机制：

• 第一阶段正常执行业务操作、提交事务，保留核心操作的主键ID（比如新建页面的pageId）
• 当后续触发回滚条件时，单独执行反向业务操作（比如根据pageId删除刚才新建的页面），不要对已经提交完成的事务实例调用rollback方法

原代码的隐性隐患 #

• 未判断事务状态就直接调用rollback()：如果事务开启阶段就抛错导致transaction为undefined，或是事务已经进入提交终态，直接调用rollback会覆盖真正的业务异常
• 回滚操作未加await：回滚是异步IO操作，不等待执行完成就返回响应，会出现接口状态正常但回滚未完成的时序问题
• 捕获异常后未向上抛出：会导致上层框架无法感知业务失败，误将接口标记为调用成功

内容的提问来源于stack exchange，提问作者mqliutie