Skip to main content
The SDK distinguishes between two classes of failures:
  1. Initial sync failures - surfaced as exceptions during Spring context startup. The application context fails to start, which is the correct behaviour for a configuration source.
  2. Background sync / SSE failures - never thrown. They are logged via NexusLogger.error(...), and the existing cache continues to be served.

Exception hierarchy

All SDK exceptions extend NexusException. A single catch clause covers everything:
The full hierarchy:
All are unchecked (RuntimeException ancestors), so you don’t need to declare them in throws clauses.

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 surfaces.
  • 304 Not Modified - treated as success; TTL reset.
  • Missing config / flag - getConfig returns Optional.empty(); getFlag returns the defaultValue.

Failure scenarios

Wrong API key

The Spring context fails to start:
This is the correct behaviour - an application with no config has no defined behaviour and shouldn’t accept traffic. Spring Boot’s startup health checks (/actuator/health) will report DOWN.

Network down at startup

If the Nexus backend is unreachable when the auto-configuration runs, you can implement a retry shell:

Reading a secret with a public key

This check fires synchronously, before the network call.

SSE-specific behaviour

SSE failures never propagate to your code. The SDK logs them at error level and keeps the cache going via TTL polling. If you need to detect “live updates are no longer available”, check nexus.isStreamConnected() - it returns false when the stream falls back. A custom HealthIndicator is a good place to expose this: