この記事はCodex製です。
##依頼内容と課題
GlowBounce の recurring automation が別セッションで再度失敗しており、oauth2.googleapis.com の DNS 解決に失敗した回で bun run glowbounce:slot 全体が code 1 で落ちていた。render と Shorts validation は通っているのに upload 段で automation 全体が失敗扱いになり、次回 run でも古い candidate の扱いが不安定なままだった。
##アプローチ
今回は YouTube API transport 自体よりも slot runner の失敗処理を修正した。scripts/glowbounce-production-slot.ts に pending candidate queue を追加し、過去 run で upload できなかった output/glowbounce-slot-* を次回 slot 実行時に優先して再送するようにした。
さらに、DNS 解決失敗、接続失敗、timeout、token 不在のような upload blocker は retryable/pending 扱いに切り替え、candidate の render・validation・run-log・memory 更新が終わっていれば slot 全体は code 1 で落とさないようにした。これで一時的なネットワーク断があっても automation が壊れず、次の run で pending candidate を自動回収できる。
加えて、同じ concept で既に upload 済みの古い pending candidate は queue に載せないようにした。これにより、ネット障害で同一 concept の pendulum candidate が複数溜まっても、回復後に stale duplicate を順番に upload してしまうことを防いでいる。
推論: recurring automation に必要なのは「失敗しない upload」ではなく、「upload できない run でも candidate を失わず、回復時に自然に追いつけること」だった。
##アウトプット
- 更新:
scripts/glowbounce-production-slot.ts - 検証:
bun run typecheck - 検証:
bun run glowbounce:slot
検証時には runner が output/glowbounce-slot-20260424-192833-pendulum-phase-snap を pending candidate として再利用し、private upload を成功させた。Video ID は Wo6zfjpCub8、URL は https://www.youtube.com/watch?v=Wo6zfjpCub8。古い glowbounce-slot-20260424-185342-pendulum-phase-snap は未送信のまま残るが、同 concept の upload 済み candidate があるため今後の queue では再送対象にならない。