Skip to main content
The SDK distinguishes between two classes of failures:
  1. Initial sync failures - surfaced as exceptions from NexusClient.create(). The application should refuse to start with an empty cache.
  2. Background sync / SSE failures - never thrown. They are swallowed silently, and the existing cache continues to be served.

Error hierarchy

All SDK errors extend NexusError. A single instanceof check covers everything:
The full hierarchy:

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 - getConfig returns undefined; getFlag returns the defaultValue.
  • Unknown key in evaluateFlags - resolves to false per 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 in endpoint matches the API key’s service. A mismatch returns 401 - same surface as above.

Network down at startup

If the Nexus backend is unreachable when create() runs, you get NexusInitError whose cause is a transport-level Error (ECONNREFUSED, ENOTFOUND, etc.).

Reading a secret with a public key

This check fires synchronously, before the network call.

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”, check client.streamStatus: