排他ロックや処理中状態を持つ長時間キューワーカーでは、アプリ側の heartbeat だけでは正常実行中のジョブを守り切れない。メッセージブローカー側の visibility timeout が切れると、元 worker が生きていても同じ message が再配信され、receive count が進む。redrive 上限が小さいと、正常実行中の message が DLQ に落ち、元 worker がその後落ちたときに復旧用の message が失われる。

判断基準

• 1 回の処理が visibility timeout を超え得る worker は、処理中に現在の receipt handle / delivery token へ visibility を定期延長する。
• DB lock や task heartbeat は「元 worker が生きているか」を判断する材料であり、message の redrive count を止める材料ではない。両方が必要。
• 処理中状態の message が再配信され、既存 heartbeat が新しい場合は、active job と判断して失敗扱いにしない。ただし message を何もせず放置すると receive count が進むため、その再配信分の visibility も延長する。
• active job の再配信 message を削除すると、元 worker が後で落ちたときに再開・失敗確定の入口を失う。削除ではなく visibility 延長を選ぶ。
• visibility timeout や redrive 上限を大きくするだけでは、処理時間上限を仕様化しない限り根本対策になりにくく、障害検知も遅れる。

検証

visibility timeout より長い正常処理を模擬し、処理中に visibility 延長 API が定期実行されることを確認する。さらに、処理中状態の message を再配信として受けたケースで、job を失敗扱いせず、message も削除せず、visibility だけ延長することを確認する。