如何在Rails控制台复现ActiveJob::DeserializationError异常

ActiveJob::DeserializationError 不会在perform方法内部触发，它是ActiveJob框架在调用perform之前，对入队时序列化存储的GlobalID参数做反序列化时抛出的——这也是你之前传不存在的记录、无效GlobalID都没法在预期位置触发错误的核心原因：你之前的操作要么在参数传给Job之前就触发了ActiveRecord查询错误，要么跳过了框架自带的参数反序列化流程，错误自然只会落在perform的业务代码段里。

标准场景复现步骤（Rails控制台执行） #

前提：不要把队列适配器设为:inline，inline模式会在perform_later调用时立刻执行任务，来不及删除关联记录，测试环境建议临时切到:async或者:test适配器。

• 先创建一条真实存在的Event记录，确保它能生成合法GlobalID

# 按你的Event模型实际必填字段补全参数
event = Event.create!(name: "test_for_job_error")

• 正常调用任务入队，框架会自动把event对象序列化为GlobalID字符串存入任务参数

WrapperJob.perform_later(event)

• 在任务被工作进程拉取执行前，删除对应的Event记录

event.destroy!

• 触发队列任务执行，不同队列适配器对应执行命令不同：
  • 用ActiveJob自带async适配器的话，等几秒等工作线程自动拉取即可
  • 用DelayedJob的话执行Delayed::Worker.new.work_off
  • 用Sidekiq测试环境的话执行Sidekiq::Worker.drain_all

执行后你会看到任务完全不会进入WrapperJob#perform里的# doing something逻辑段，直接抛出ActiveJob::DeserializationError，且因为配置了discard_on ActiveJob::DeserializationError，任务会被直接标记为丢弃，不会进入重试流程。

快捷复现方式（无需走完整入队删数流程） #

如果不想走完整队列流程，可以直接模拟框架的反序列化逻辑，手动构造序列化后的任务参数触发错误：

# 先从任意真实记录拿你应用的GID前缀，比如随便找一条存在的Event执行：
# Event.first.to_global_id.to_s  输出类似 gid://your-rails-app/Event/1，把前缀部分替换到下面
job = WrapperJob.new
serialized_job_data = {
  "job_class" => "WrapperJob",
  "arguments" => [{"_aj_globalid" => "gid://your-rails-app/Event/99999999"}] # 填一个不存在的Event ID
}
job.deserialize(serialized_job_data)

# 执行时会在参数解析阶段直接抛出DeserializationError，不会进入perform内部逻辑
begin
  job.perform_now
rescue ActiveJob::DeserializationError => e
  puts "成功捕获目标异常：#{e.class}"
end

避坑提示：不要直接给perform_now传GlobalID.new("gid://xxx/Event/9999")这类手动构造的无效对象，这种传参方式会让框架直接把对象透传到perform方法里，不会走反序列化校验流程，自然不会抛出目标异常。

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