## What — schedule は下流から、retry は冪等性から - **日次にした理由**：CSV の提供時刻・曜日が先方依存で読めない。冪等なので空振りしても無害で、提供遅延にも自動追従する（週次だと取りこぼす） - **早朝にした理由**：下流の dbt モデリング開始より前に置けば「提供翌朝には mart で使える」 - **分をずらす理由**：`:00` への実行集中を避ける負荷分散 - **max_retries = 1 の理由**：CRC32C で冪等なので再試行しても二重取込にはならない（＝再試行は安全）。ただし失敗原因の多く（権限・設定ミス）は再試行しても直らないので 1 回で止め、Slack 通知で人が見る 冪等性は「リトライしていいか」を決めるだけで、「リトライする意味があるか」は別問題だ。 ## How — Scheduler の retry_config は Job のリトライではない `retry_config`（3回、30〜300s）は Job 本体のリトライではなく、Scheduler → ディスパッチャの **HTTP 呼び出し失敗時**のリトライ（リポジトリ多数派パターン）。 handler は全滅時のみ 500 を返す実装なので、部分成功（200）だとリトライされない。失敗テナントは翌日の日次実行が敗者復活戦になる。 「日次 × 冪等」がリトライの穴を埋めている。逆に言うと、週次にした瞬間にこの穴は1週間開きっぱなしになる。スケジュールとリトライは別々に決められない。 > [!success] > 過去のレビュー実績も同じところを突いてくる。「この時刻にしてる理由は？dbt の開始より前に」——時刻には根拠が求められる。 ## 関連 - [[Google Cloud]] - [[Cloud Run Jobの設定値の決め方]] — 設定値全体の一覧と方針 - [[Cloud Run Jobのcpuとmemoryの決め方]] — リソース側の根拠 - [[APIとJobの違い]]