更新時刻の降順リストをページ番号で走査し、前回以降の変更だけを処理する差分バッチでは、checkpoint にバッチ完了時刻を保存すると取りこぼしが起きる。走査中にレコードが更新されて先頭ページへ移動すると、現在の後続ページから外れる一方、更新時刻が完了checkpoint以前なら次回も対象外になり、永久に未処理になるためである。

判断と手順

• 最初のページを取得する直前に走査開始時刻をwatermarkとして固定する。
• 成功後のcheckpointには完了時刻でなく、その開始watermarkを保存する。
• 次回は更新時刻がcheckpointと等しいレコードも再検査し、checkpointより古いレコードに到達して初めて停止する。等値の重複処理は、更新中の取りこぼしを防ぐための意図的な安全側である。
• 各処理は冪等にするか、処理済み判定を別に持ち、境界再検査による二重副作用を防ぐ。

適用条件と限界

これは、APIが更新時刻順のoffset/page paginationしか提供せず、走査中にも外部更新が起こり得る定期差分処理の回復策である。走査中に同じ集合を自分で更新する一括処理や、厳密に一度だけの全件処理が必要な場合は、安定したkeyset cursorや開始時点のID snapshotを優先する。開始watermark方式は現在の走査での漏れを次回へ繰り越して回収するのであり、単発実行だけで完全性を保証するものではない。

検証

複数ページを走査し、先頭ページ取得後に後続ページのレコードを更新して先頭へ移動させる。現在の走査ではそのレコードが漏れても、次回の開始watermark境界で必ず再取得されることを確認する。対照として完了時刻をcheckpointへ保存すると、同じレコードが次回も対象外になることを再現する。