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週間開きっぱなしになる。スケジュールとリトライは別々に決められない。

関連

• Google Cloud
• Cloud Run Jobの設定値の決め方 — 設定値全体の一覧と方針
• Cloud Run Jobのcpuとmemoryの決め方 — リソース側の根拠
• APIとJobの違い