Skip to main content
A small utility for retrying REST calls that fail transiently. Useful around:
  • connect() immediately after plugging in a camera (takes a few seconds to be ready)
  • SSE reconnection (already baked into Recipe 1, but reusable elsewhere)
  • Network blips between the client and server
  • The 500ms server-side settle race after connect

When to use

  • Any code path where “try a few times with delay” is the right recovery
  • Wrapping connect() so you don’t fail immediately on a half-ready camera
  • CI tests that need to wait for server readiness

When NOT to use

  • Hard errors that won’t get better with retry (400 Bad Request, 404 Not Found) — retry these and you just burn time
  • Long-running ops (downloads, live view) — retry the kickoff, not every iteration

Key insight: retry on the right errors

Not every error should retry. A 400 "Invalid property value" will fail identically on retry; a 400 "Camera not ready" probably won’t. The recipes below let you supply a predicate.

TypeScript

Complete recipe

Usage — retry camera connect with a “camera not ready” predicate

Usage — wait for the server to be ready


Python

Complete recipe

Usage


Swift

Complete recipe

Usage


When to retry vs. give up

A good shouldRetry predicate dramatically reduces wasted time: If in doubt: retry network-layer errors, don’t retry validation errors. The recipes above default to retrying everything, which is safe but sometimes wasteful; supplying a predicate is the tuned path.

Combined with the connect→priority-key race

A common use is wrapping the connect + priority-key sequence so both settle races are handled automatically:
This single helper eliminates 90% of “camera not ready” flakiness in real apps.

Verified against

The retry pattern was validated during the multi-mode test runs — the 500ms sleep in connectWithPriority is the shortcut version of this recipe. A full retry wrapper is better when conditions are less predictable.