X reply pollingの重複処理を減らす――cursor・cache・再取得範囲

一定間隔の取得で取りこぼしを避けながら、同じreplyを毎回action実行しないために何を保存するか。

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

1. polling scheduler、reply trigger cache、そのtest、polling/replier cache migrationが公開される。
2. 最後に見た時刻だけでは同時刻eventや遅延反映を落とす可能性があり、ID cursorと重複cacheの組合せを検討する必要がある。
3. 取得範囲を重ねると欠測は減るがAPI callと重複判定が増える。観測は取りこぼし率とcall数の両方を報告する。

再現・追加測定の手順

1. 複数replyを短時間に作る
2. polling間隔境界でreplyを追加する
3. 同一範囲を繰返し取得する
4. 取得件数・新規判定・action件数・API callを記録する

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

1. テストaccountのreply量は高流量accountを再現しない。
2. X APIの検索・timeline反映遅延は一定ではない。

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