[riglar]

Why

When the CLI uploads a binary, it uploads to Backblaze B2 and to Supabase. It fails only if both uploads fail. The B2 upload made one attempt per request, with no retry. So a single 503 or dropped connection on any large-file part failed the whole B2 upload, and the Supabase upload was the only thing left to save the run. When that also failed, the run failed.

The B2 error was also hidden. When both uploads failed, the CLI reported only the last error, which was the Supabase one. That made a B2 failure look like a Supabase problem.

B2 expects clients to retry. Its docs say uploads can get 503 / 500 / 408 or a dropped connection, and the client should back off and try again. After a 503 on a large-file part, it should use a different upload URL.

What changes

• New src/utils/b2-retry.ts. Each B2 request gets up to 4 attempts, with jittered exponential backoff (about 1 s, 2 s, 4 s, capped at 8 s). It retries on network errors (TypeError) and 408 / 429 / 5xx. Other 4xx responses fail straight away.
• Large-file parts switch to another upload URL on each retry (partUploadUrlFor). The API mints one URL per part. Each URL is tied to the file, not to a part number (the part number is sent in X-Bz-Part-Number), so any URL can upload any part. Parts upload one at a time, so no URL is ever used twice at once. A 401 is retried only here, because the next attempt uses a URL with a different token.
• The simple upload (pre-signed S3 PUT, under 50 MB) retries the same URL.
• B2 errors now reach the user. uploadToBackblaze and uploadLargeFileToBackblaze throw instead of returning false, so handleBackblazeUpload passes the error up. When every upload fails, validateUploadResults puts Backblaze error: … before the existing Last error: {…}. That part of the message keeps its old format.

There's no API change. The worst case adds about 7 s per failing part before giving up.

Testing

• pnpm lint shows no new warnings (the same 24 as dev). pnpm typecheck, pnpm test:unit (489 passing) and pnpm build all pass.
• New test/unit/b2-retry.test.ts covers:
  • which errors are retried
  • retry, then success
  • stopping on a 4xx that isn't retried
  • giving up after the attempt limit
  • the backoff bounds
  • URL rotation
  • the combined error message
• Not tested against real B2. The retry path only runs when B2 fails, and I had no way to make it fail on demand.

🤖 Generated with Claude Code

[claude]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

🤖 Generated with Claude Code