Skip to content

feat(client): add exponential backoff for status checks - #1212

Merged
badayvedat merged 5 commits into
mainfrom
vedat/plat-5625-add-exp-poll-backoff-for-status-checks
Oct 21, 2026
Merged

badayvedat merged 5 commits into
mainfrom
vedat/plat-5625-add-exp-poll-backoff-for-status-checks

Conversation

@badayvedat

@badayvedat badayvedat commented Oct 11, 2026 •

Copy link
Copy Markdown
Contributor

Before, the client polled the queue status endpoint at a fixed interval. After, the client uses exponential backoff: the first delay is 250 ms, each base delay grows by 1.05x, capped at 10 s, with +/-20% jitter per delay (also capped at 10 s). A fixed interval can still be requested explicitly.

When the observed request status changes (for example, IN_QUEUE → IN_PROGRESS), backoff resets to 250 ms by default so a long queue wait does not slow completion detection once running. Queue-position and log updates do not reset it. COMPLETED stops polling without another sleep. Explicit fixed intervals remain unchanged.

Chart and table assume no status transitions. Backoff resets to its initial delay on an observed status change; polling stops on COMPLETED.

Numbers below use the base curve without jitter and assume zero request latency. Request latency reduces polling counts; jitter can change them in either direction.

30 s 1 min 2 min 5 min 10 min
Before: fixed 100 ms
Status calls so far 301 601 1,201 3,001 6,001
Delay between checks at this point 100 ms 100 ms 100 ms 100 ms 100 ms
After: 250 ms × 1.05 per check, max 10 s
Status calls so far 40 53 66 87 117
Delay between checks at this point 1.68 s 3.16 s 5.96 s 10.00 s 10.00 s
polling-python-before-after

Note

Medium Risk
Default polling behavior changes for all callers that relied on implicit fixed-interval waits, which affects queue load and how quickly completion is detected unless interval is set explicitly.

Overview
Queue status polling no longer defaults to a fixed 100 ms interval. It now uses configurable exponential backoff via a new public PollBackoff type (defaults: 250 ms start, 1.05× growth, 10 s cap, ±20% jitter), exported from the package.

iter_events, get, and sync/async subscribe accept optional backoff and treat interval as optional (None → backoff). An explicit interval still forces fixed spacing and overrides backoff. When using backoff, the delay sequence resets on a change in status kind (e.g. Queued → InProgress), not on queue-position or log-only updates; completion returns without an extra sleep.

DEFAULT_QUEUE_POLL_INTERVAL remains for import compatibility but is documented as deprecated for polling behavior. Unit tests cover PollBackoff validation and sync/async polling sleep patterns.

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

@linear-code

linear-code Bot commented Oct 11, 2026

Copy link
Copy Markdown

PLAT-5625

@claude claude Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

Comment thread projects/fal_client/src/fal_client/client.py
@badayvedat
badayvedat force-pushed the vedat/plat-5625-add-exp-poll-backoff-for-status-checks branch from c8e7df5 to 9d376e0 Compare October 16, 2026 17:13
@bberkay-sahin

Copy link
Copy Markdown
Contributor

LGTM, ty @badayvedat

@bberkay-sahin

Copy link
Copy Markdown
Contributor

one suggestion only might be about the numbers, but we can arrange it if there will be any complaint

@badayvedat
badayvedat merged commit 8f4b4c4 into main Oct 21, 2026
31 of 34 checks passed
@badayvedat
badayvedat deleted the vedat/plat-5625-add-exp-poll-backoff-for-status-checks branch October 21, 2026 20:35
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.

2 participants