Skip to main content
Every error raised by the nelieo-nsp SDK is a subclass of NSPError. Catching the right exception at the right level lets you distinguish between transient network failures, authentication problems, missing apps, and application-level action failures — and handle each one appropriately.

Exception Hierarchy

Base Error Fields

Every NSPError subclass exposes these three attributes:

Exception Reference

When raised: The daemon is not running, is not listening on the configured host and port, or an existing connection was dropped during a request.HTTP status: 0 (no HTTP response received)Fields:
  • e.message — description of the connection failure
  • e.code"connection_refused" or "connection_reset"
  • e.status_code0
How to handle:
Common causes:
  • Daemon not started
  • NSP_PORT does not match AXON_SERVER__PORT in your daemon config
  • Firewall rule blocking localhost connections
When raised: The API key is absent, malformed, expired, or has been disabled on the daemon.HTTP status: 401Fields:
  • e.message — human-readable auth failure description
  • e.code — one of "missing_key", "invalid_key", "disabled_key"
  • e.status_code401
How to handle:
Generate a fresh key and set it as an environment variable or pass it to NSPClient(api_key=...).
When raised: The app name, app_id, or PID you requested does not exist in the daemon’s tracked list.HTTP status: 404Fields:
  • e.message — which resource was not found
  • e.code"app_not_found" or "pid_not_found"
  • e.status_code404
How to handle:
When raised: You have exceeded the daemon’s per-key rate limit for state reads or action dispatches.HTTP status: 429Fields:
  • e.message — rate limit description
  • e.code"rate_limit_exceeded"
  • e.status_code429
  • e.retry_afterfloat — minimum seconds to wait before retrying
How to handle with exponential backoff:
Default limits: 100 state reads/sec and 10 actions/sec per API key. Adjust in axon.toml.
When raised: A request exceeded NSPClient’s timeout setting, or a fresh probe cycle did not complete within the daemon’s probe timeout.HTTP status: 504Fields:
  • e.message — what timed out
  • e.code"request_timeout" or "probe_timeout"
  • e.status_code504
How to handle:
When raised: The probe’s confidence score is below the minimum required to execute the requested action. This prevents the SDK from acting on stale or incomplete state.HTTP status: 422Fields:
  • e.message — description including current and required confidence
  • e.code"confidence_too_low"
  • e.status_code422
  • e.current_confidencefloat — the probe’s current score
  • e.required_confidencefloat — minimum score needed
When this happens:
  • The app was just detected and the first probe is not yet complete
  • The app navigated to a new view and confidence dropped temporarily
  • A native app with inherently variable confidence
How to handle:
When raised: The action was dispatched to the runtime but failed — either because the application rejected it, the action’s internal logic errored, or post-action verification did not pass.Fields:
  • e.message — human-readable failure description
  • e.code — machine-readable error code (e.g. "clr_invoke_timeout", "verification_failed")
  • e.actionstr — name of the action that failed
  • e.verification_failedboolTrue if the action ran but verify_expression returned falsy
How to handle:
When raised: You called session.execute() on an IrreversibleWrite action without explicitly setting verify=True. The SDK enforces this check locally before sending any request to the daemon — no network round-trip is wasted.Fields:
  • e.message — explanation of why the call was rejected
  • e.code"irreversible_not_confirmed"
  • e.actionstr — name of the irreversible action
How to handle:

Comprehensive Try/Except Pattern

Use this template as the foundation for any production agent:
Never silently swallow NSPConnectionError or NSPAuthError. These indicate conditions that require operator action and cannot be resolved by retrying.