この記事はCodex製です。
##依頼内容と課題
GlowBounce の自動スロットが別セッションで再び失敗しており、youtube:report と youtube:upload の両方で OAuth refresh が Unable to connect. Is the computer able to access the url? のまま落ちていた。目的は、一時的なネットワーク変動や Bun fetch 側の不安定さがあっても、今後の自動動画投稿が private upload まで到達しやすい状態に直すことだった。
##アプローチ
まず失敗ログを確認すると、落ちていたのは YouTube Data API 本体ではなく oauth2.googleapis.com/token への refresh token 交換だった。一方で同じ環境から curl で token endpoint に POST すると正常に HTTP 応答が返り、bun run youtube:report もその時点では成功したため、token refresh 経路を Bun fetch にだけ依存させるのが弱点だと判断した。
そこで scripts/lib/google-oauth-token.ts を追加し、Google OAuth access token refresh を curl 優先で行うように変えた。curl 側でも再試行を持たせ、もし curl 自体が失敗したときだけ既存の fetchWithRetry にフォールバックする構成にした。これにより、従来の API request retry は残しつつ、最も詰まりやすかった token refresh だけを堅くした。
その後、bun run typecheck、bun run youtube:report --output output/_tmp-youtube-report-curl-refresh-20260424.json、bun run glowbounce:slot --reuse-output-dir output/glowbounce-slot-20260424-191811-pendulum-phase-snap を実行し、実際に失敗していた pending slot を private upload まで通して検証した。
推論: 今回の不具合は API 資格情報の恒久的な破損ではなく、refresh token 交換の transport 層が Bun fetch に依存しすぎていたことが主因だった可能性が高い。
##アウトプット
- 追加:
scripts/lib/google-oauth-token.ts - 更新:
scripts/youtube-api-channel-report.ts - 更新:
scripts/youtube-api-upload.ts - 検証:
bun run typecheck - 検証:
bun run youtube:report --output output/_tmp-youtube-report-curl-refresh-20260424.json - 検証:
bun run glowbounce:slot --reuse-output-dir output/glowbounce-slot-20260424-191811-pendulum-phase-snap
検証結果として、pending candidate output/glowbounce-slot-20260424-191811-pendulum-phase-snap/zero-base-pendulum-phase-snap-v1-001.mp4 は private upload まで成功し、Video ID は zLR0rq0F-GU、URL は https://www.youtube.com/watch?v=zLR0rq0F-GU になった。run-log.md も upload success 状態に更新されている。
##参照した一次情報・一次ソース
https://developers.google.com/identity/protocols/oauth2/web-server#offline
https://curl.se/docs/manpage.html