失敗したジョブはどうなりますか。
指定回数リトライし、超えると failed_jobs テーブルに落ちます。回数と間隔は tries と backoff で指定します。sync ドライバの同期実行はここに入らない点が落とし穴です。
面接官が見ているのは「投げたら終わり」になっていないか。
これは「どういう処理をキューに逃がすのが妥当ですか。」への追撃質問です。
よくある答えと、面談でどう見られるか
- 指定回数リトライし、超えると failed_jobs テーブルに記録される
その通りです。重要なのは、落ちたことに誰も気づかない状態を作らないこと。failed() で通知を飛ばすか、failed_jobs の件数を監視します。 - 自動的に無限リトライされ続ける
tries で上限があります。無限だとワーカーが詰まります。 - 何も記録されずに消える
failed_jobs に残ります。ただし見に行かなければ気づけないのは事実です。 - 例外がそのままユーザーの画面に表示される
別プロセスで動いているので、ユーザーのリクエストとは既に切り離されています。だからこそ気づきにくいのです。
面接官は何を見ているか
- リトライ回数（tries / backoff）に触れた
- failed_jobs テーブルに記録されることを知っていた
- 失敗に気づく仕組み（通知 / 監視）に触れた
模範解答
指定回数リトライし、超えると failed_jobs テーブルに落ちます。tries と backoff で回数と間隔を指定します。注意点として、failed_jobs に入るのは非同期で投げたジョブだけです。sync ドライバで同期実行したジョブの失敗は記録されず、その場で通常の例外として扱われます。開発環境が sync だと、失敗の記録を確認する導線ごと存在しないことになります。重要なのは、落ちたことに誰も気づかない状態を作らないことです。failed() メソッドで通知を飛ばすか、failed_jobs の件数を監視します。復旧は queue:retry で再投入できます。
ここからどう深掘りされるか
この問いに答えられた場合、面談は次の質問に進みます。
観点をすべて押さえられた場合
トランザクションの中で dispatch したジョブが「レコードが見つからない」で失敗しました。なぜですか。