Sidekiq异步任务执行报错时，如何丢弃所有已产生的数据库变更？

最小改动实现方案：ActiveRecord 数据库事务 #

无需修改现有业务逻辑，仅需在Worker的perform方法外层加一层ActiveRecord事务包裹即可实现所有操作的原子性：任意环节抛出异常时，事务内的所有数据库写操作会自动全部回滚，没有脏数据残留。
代码示例：

class BatchCreateWorker
  include Sidekiq::Worker

  def perform(params)
    # 仅新增这一层事务包裹，原有业务代码完全不需要调整
    ApplicationRecord.transaction do
      # 原有业务逻辑 保持不变
      user = User.create!(user_params)
      category = PostCategory.create!(category_params.merge(user_id: user.id))
      post = Post.create!(post_params.merge(category_id: category.id))
      10.times { Comment.create!(comment_params.merge(post_id: post.id)) }
    end
  end
end

注意事项 #

• 所有写操作要使用带!的方法（create!/save!/update!）：这类方法执行失败时会直接抛出异常触发事务回滚；如果使用不带!的方法，需要自行判断返回值，失败时手动抛出异常才能触发回滚。
• 如果项目使用多数据库，需要按照Rails多数据库事务的语法调整，确保所有关联写操作都在同一个事务范围内。

Sidekiq 相关能力说明 #

Sidekiq本身没有内置业务层的数据一致性校验能力，它的核心职责是任务调度、失败重试、死信队列管理。搭配上述事务方案使用时，任务执行失败触发回滚后，Sidekiq的重试机制会自动重新执行整个任务，全程不会有无效数据落库。

其他可选调研方向 #

如果你的场景包含非数据库操作（比如调用第三方接口、文件写入等无法纳入数据库事务的操作），可以参考以下实现思路：

• 补偿模式：为每个执行步骤编写对应的逆操作逻辑，捕获异常后按执行的逆序调用补偿方法（比如创建Post失败时，先删除已创建的PostCategory，再删除已创建的User），实现数据清理。
• 状态标记模式：所有写入的数据先标记为「草稿/未生效」状态，全流程执行完成后统一更新为「生效」状态，后台定时清理超时未生效的草稿数据，适合需要保留失败现场排查问题的场景。

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