- Initial sync failures - surfaced as exceptions from
NexusClient.create(). The application should refuse to start with an empty cache. - Background sync / SSE failures - never thrown. They are swallowed silently, and the existing cache continues to be served.
Error hierarchy
All SDK errors extendNexusError. A single instanceof check covers everything:
When each is thrown
What is NOT thrown
- Background syncs - silently retried on the next TTL tick. Cache served.
- SSE transport errors - exponential backoff, 3-strike fallback to polling. No exception.
304 Not Modified- treated as success; TTL reset.- Missing config / flag -
getConfigreturnsundefined;getFlagreturns thedefaultValue. - Unknown key in
evaluateFlags- resolves tofalseper the server contract; never throws.
The asymmetry between secrets (throw) and configs/flags (sentinel) is deliberate: a missing secret usually means “you’re misconfigured, fail fast”, while a missing flag usually means “use the safe default and continue”.
Failure scenarios
Wrong API key
Slug doesn’t match key (Double-Gate failure)
In production, the backend validates that the slug embedded inendpoint matches the API key’s service. A mismatch returns 401 - same surface as above.
Network down at startup
If the Nexus backend is unreachable whencreate() runs, you get NexusInitError whose cause is a transport-level Error (ECONNREFUSED, ENOTFOUND, etc.).
Reading a secret with a public key
Reading a secret that doesn’t exist
Reading a non-existent flag or config
Returns the default - no error:SSE-specific behaviour
SSE failures never propagate to your code. The SDK silently logs them and falls back to polling after 3 strikes. To detect “live updates are no longer available”, checkclient.streamStatus:
