Skip to content

app: /api/hiro-proxy returns sustained 429s - balances blank and swaps affected (incl. via Leather); client retries without backoff #25

Description

@Rapha-btc

Summary

app.bitflow.finance is currently unusable for stretches of time because the app's own Stacks API proxy (/api/hiro-proxy/extended/v3/principals/.../balances/...) returns a sustained stream of 429 Too Many Requests. The console fills with hundreds of failed balance requests, balances do not load, and swap flows are affected as well — including swaps initiated from inside the Leather browser extension, which go through the same rate-limited path.

What it looks like

  • Every balance call (.../balances/stx, .../balances/ft?limit=50) through /api/hiro-proxy/... fails with 429.
  • The frontend's react-query polling (setInterval -> updateRefetchInterval -> executeFetch, visible in the stack traces) retries the same requests every few seconds with no backoff, so the app keeps re-tripping the limit as fast as the quota window resets.
  • Fully closing and reopening the browser does not help — which points at the proxy's shared upstream API key quota being exhausted server-side, not per-client state.

Why it compounds

Because the proxy funnels all users through one upstream quota, any single page that polls aggressively consumes the budget for everyone. And since the client neither respects Retry-After nor pauses its refetch intervals on 429, each open tab keeps hammering, which keeps the quota pinned at zero for all users.

Suggestions

Any one of these would help; together they would make the app resilient:

  1. Server-side caching / request coalescing on the proxy for identical balance queries (even a 5-10s TTL would collapse most of the polling traffic).
  2. Backoff on 429 in the client: respect Retry-After, pause the react-query refetchInterval while rate-limited, and resume after the window resets — instead of immediate fixed-interval retries.
  3. Keep last-known data on failure rather than blanking balances: a rate-limited read is "unknown", not "zero".
  4. Raise the upstream API key tier / shard keys if aggregate traffic has simply outgrown the current quota.

Environment

  • app.bitflow.finance production (deployment id visible in asset URLs: dpl_Ba5WFkvcFFsqH5Hqh8rm27sozkeM)
  • Reproduced across full browser restarts; multiple principals' balance endpoints affected identically.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions