Skip to content

chore(release): bump bridge-core to 0.1.22 - #92

Merged
Yoni-Starkware merged 1 commit into
mainfrom
chore/release-0.1.22
Aug 23, 2026
Merged

Yoni-Starkware merged 1 commit into
mainfrom
chore/release-0.1.22

Conversation

@Yoni-Starkware

@Yoni-Starkware Yoni-Starkware commented Aug 23, 2026 •

Copy link
Copy Markdown
Collaborator

Ships #91. One line: packages/bridge-core/package.json 0.1.21 → 0.1.22.

Why this release is urgent

0.1.21 has a field regression, and 0.1.22 is the fix.

0.1.20 and earlier ran retryCount: 6, retryDelay: 250 — seven attempts across 15.75s of doubling backoff. That backoff was functioning as an accidental rate limiter. A cold chain scan was breaching the provider's compute-units-per-second ceiling routinely, but every 429 was absorbed and re-sent slowly enough that nothing ever surfaced to the user. The scan was slow; it was not broken.

0.1.21 did two things at once:

  1. cut the budget to retryCount: 2, retryDelay: 250 — 0.75s of total backoff, 1/21st of the cushion; and
  2. made each scan wave both cheaper (balances batch into one aggregate3) and faster.

Cost per wave went down; waves per second went up. Because the provider's limit is a rate, not a total, the sustained CU/s actually rose — and with the retry cushion gone, the breach stopped being invisible and started surfacing as exceeded its compute units per second capacity.

What 0.1.22 changes

0.1.22 keeps the small attempt count — six retries could outlast a caller's entire scan timeout, which is why it was cut and that reasoning still holds — while restoring genuine pacing:

version attempts total backoff first retry lands
0.1.20 7 15.75s same rate period
0.1.21 3 0.75s same rate period
0.1.22 3 3.00s next rate period

The retryDelay matters more than the count here: viem waits exactly retryDelay before attempt two, so at 250ms all three attempts land inside one second and none of them can pass a per-second ceiling. At 1000ms each attempt gets a fresh window.

Note

This is a real mitigation, not a complete fix. A cold scan is still structurally over budget on a free-tier key — 0.1.22 makes it degrade gracefully (slow, self-paced, absorbed) instead of erroring. Fitting inside the ceiling needs explicit CU pacing on the consumer side, tracked separately.

🤖 Generated with Claude Code


This change is Reviewable

Ships #91 — `RPC_RETRY_DELAY_MS` 250ms -> 1000ms, so viem's first retry lands in a
FRESH rate period instead of re-spending a per-second budget that has not refilled.

This one is worth releasing promptly, because 0.1.21 has a field regression that
0.1.22 is the fix for. 0.1.20 and earlier ran `retryCount: 6, retryDelay: 250` —
seven attempts across 15.75s of doubling backoff. That backoff was an accidental
rate limiter: a cold chain scan breached the provider's compute-units-per-SECOND
ceiling constantly, but every 429 was absorbed and re-sent slowly enough that
nothing ever surfaced to the user. 0.1.21 cut the budget to `retryCount: 2,
retryDelay: 250` — 0.75s of total backoff, 1/21st of the cushion — and at the same
time made each scan wave cheaper AND faster. Lower cost per wave, but waves issued
far more often: the SUSTAINED rate went up, and with the cushion gone the breach
became a visible "exceeded its compute units per second capacity" error.

0.1.22 keeps the small attempt count (six retries could outlast a caller's whole
scan timeout, which is why it was cut) while restoring real pacing: 3.0s of
backoff, spread ACROSS rate periods rather than inside one.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@cursor

cursor Bot commented Aug 23, 2026 •

Copy link
Copy Markdown

PR Summary

Low Risk
Package version bump only; no code, auth, or data-handling changes.

Overview
Bumps @starkware-libs/starknet-privacy-bridge from 0.1.21 to 0.1.22 in packages/bridge-core/package.json so the retry-pacing fix can be published.

Reviewed by Cursor Bugbot for commit 58a52d5. Bugbot is set up for automated code reviews on this repo. Configure here.

@Yoni-Starkware
Yoni-Starkware merged commit 3e95694 into main Aug 23, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant