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. A400 "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 goodshouldRetry 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:Verified against
The retry pattern was validated during the multi-mode test runs — the 500mssleep in connectWithPriority is the shortcut version of this recipe. A full retry wrapper is better when conditions are less predictable.
