feat: retry failed Bunny operations with exponential backoff#3
Merged
Conversation
Transient 5xx/network errors during upload, delete, list, or purge aborted the whole deploy. Add a withRetry helper (exponential backoff + jitter) and wrap every BunnyClient network call in it, logging each retry. Uploads re-open the read stream per attempt (streams are single-use). Exposed as a new `retries` builder option (default 3, 0 = fail fast). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds resilience to transient Bunny API failures (5xx / network blips) during a deploy. Driven by tests first (TDD).
What
src/retry.ts—withRetry(fn, { retries, baseDelayMs, onRetry }): runsfn, and on rejection waits with exponential backoff + jitter and retries, up toretriesextra attempts, then rethrows the last error.BunnyClientwiring —upload,remove,purgePullZone, and eachlistinlistAllnow go throughwithRetry, logging awarnper retry. Uploads re-open the read stream inside the retried fn (a stream is single-use, so a naive retry would send truncated data).retriesoption (schema.json+DeployOptions, default 3,minimum: 0;0= fail fast). Threaded fromdeploy.tsinto the client.Behaviour with the existing flow
Uploads retry before
runWithConcurrencyaborts; deletes retry before being counted as a best-effort failure; the purge retries before the orchestrator downgrades it to a warning. No change to that orchestration logic.Verification
pnpm test→ 42/42 (+6: fullwithRetryunit suite + aBunnyClientupload-retry test that also closes the previously-untested upload path). Both confirmed RED before the implementation.pnpm run typecheckclean,pnpm run build+ dist smoke OK.🤖 Generated with Claude Code