fix: 提出ページが404のコンテストは即スキップしてクロールを高速化する

[kenkoooo]

背景 / 原因

issue #1518 / #1520 で「abc308 / abc358 / abc410(CodeQUEEN 予選に流用された回)への 2026-01 以降の提出が反映されない」と報告されている。AWS(ECS + CloudWatch Logs)で本番クローラのログを確認したところ、コンテスト固有の問題ではなく 古い全コンテスト共通の取りこぼしであり、原因は提出クロールの周回が遅すぎることだった。

submissions のクロール (crawler_utils::fetch_submissions) は すべてのエラーを一律に最大10回・指数バックオフ(2s→4s→…→1024s, 合計約34分)でリトライする。提出ページが 404 を返す古い/非公開コンテストに対してもこのリトライが走るため、該当コンテスト1件につき最大約34分を空費していた。

実際のログでは:

• crawl-new が起動から5時間以上経っても1周目の途中で、404 を返すコンテストのリトライ(attempt 10/10)で延々と待たされていた
• crawl-all は別要因(巨大コンテストの全ページクロール)で詰まる

その結果、古いコンテストを唯一カバーできる crawl-new / crawl-all が1周しきれず、abc308 等への新規提出が反映されなかった。

なお fetch_problems 側はすでに 404 を CrawlerError::NotFound で即スキップしており、submissions 側だけこの分岐が欠けていた。

変更

• crawler/src/client.rs の fetch_submissions: 404 を CrawlerError::NotFound として返す(fetch_problems と同じ扱い)
• crawler_utils.rs の fetch_submissions(リトライ層): NotFound はリトライせず即スキップ。429(Too Many Requests) や 5xx など他のエラーは従来どおりリトライする

効果

404 コンテストでの最大約34分の浪費がなくなり、crawl-new の1周時間が大幅に短縮される。古いコンテスト(abc308/358/410 含む)への提出も現実的な周期で拾われるようになる。レート制限/一時障害に対するリトライ耐性は維持。

確認

• cargo build --bin crawl-submissions パス
• cargo clippy -p crawler --all-targets -- -D warnings / cargo clippy --bin crawl-submissions -- -D warnings パス

Closes #1518
Closes #1520

🤖 Generated with Claude Code