L Harnessの一斉配信は二重送信をどう抑えるか――冪等性・再試行・重複排除のコード読解

タイムアウトやCron重複が発生したとき、同じ受信者へ同じ配信を再送する経路をどこで識別し、どの層で止める設計か。

コードから観測できること

1. HTTP入口のbroadcasts.tsとは別に、配信処理、retry key、複数アカウント重複排除が別モジュールへ分離されている。冪等性は単一のif文ではなく、受付・実行・再試行の複数境界で読む必要がある。
2. D1側には配信キュー用migrationとbroadcastsデータアクセス層があり、UI上の作成状態と実際の送信処理を同一状態として扱わない構造になっている。
3. 冪等性、retry key、dedupには対応するテストファイルが存在する。仕様を説明するときは実装ファイルだけでなく、どの入力を重複と見なすかをテストケースから確認する必要がある。

再現・追加測定の手順

1. テスト用アカウントと受信者を用意する
2. 同じ配信IDに対する実行要求を短時間に複数回発生させる
3. D1のキュー状態、送信ログ、retry keyを時系列で保存する
4. 受信件数と内部試行回数を分けて報告する

この資料だけでは証明できないこと

1. コード読解だけではCloudflare障害やLINE側タイムアウトを完全再現できない。
2. 重複排除は正当な再送まで止める可能性があるため、誤送信率だけでなく未送信率も測定対象にする。

このページは新しいcommit、実測ログ、API仕様変更が得られた時点で更新します。古い観測条件と現在仕様を混同しないため、固定commitへのリンクを残します。