キューワーカーの graceful shutdown で、処理ハンドラの in-flight 集合だけを待っても安全とは限らない。long polling などの receive 要求は handler とは別の in-flight 処理であり、receive の待機中に shutdown が始まると、ブローカー側では message を受信済み・不可視化したのに、アプリ側が応答を無視して終了する競合が起きる。message は visibility timeout が切れるまで他 worker から取得できず、処理ログがないまま backlog だけ遅延する。

判断基準

• shutdown flag は次の receive 開始を止めるだけでなく、すでに待機中の receive もライフサイクル管理の対象にする。
• 待機中の receive は abort するか、完了まで待つ。shutdown 後に message が返った場合は、処理して drain するか、visibility を戻して再配信可能にする。受信結果を黙って捨てない。
• shutdown hook は handler の集合と receive/pump 自体の両方を待つ。実行基盤の停止猶予を超え得る場合は、abort と再配信を優先し、完全処理を無期限に待たない。

検証

receive を遅延可能な promise に置き換え、receive 待機中に shutdown を開始してから message を返す競合を再現する。shutdown 完了が receive の扱いを確定するまで待つこと、message が処理または再可視化されること、shutdown flag 設定後に追加 receive が始まらないことを確認する。通常の「handler 実行中に shutdown」だけではこの競合を通らないため、別ケースとして固定する。