16.7 Recoverable and Non-Recoverable Errors [Dido Solutions, Inc Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 16.7 Recoverable and Non-Recoverable Errors ======

[[fxdemo:05-part:start | Go To Top ]]

[[fxdemo:05-part:16-exception-handling:start | Return to Exception Handling ]]

The team should distinguish recoverable errors from non-recoverable errors. This distinction helps Nodes choose between continuing, entering Degraded state, entering Recovering state, stopping, or failing.

A recoverable error allows a Node, script, or containerized process to continue safely after reporting the issue. Examples may include:

  - Unsupported command received and rejected.
  - Optional tool missing from the local environment.
  - Temporary failure to receive a non-critical message.
  - Validation warning that does not block the selected workflow.
  - Non-critical log export issue where primary logs remain available.

A non-recoverable error prevents the required operation from continuing safely. Examples may include:

  - Missing required [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration|Configuration]].
  - Invalid required Configuration.
  - [[dido:99_annexes:annex-b-terms-and-definitions:d:dds|DDS]] participant creation failure.
  - Required generated type missing.
  - Required container image build failure.
  - Required [[dido:99_annexes:annex-b-terms-and-definitions:n:node|Node]] startup failure.
  - Required [[dido:99_annexes:annex-b-terms-and-definitions:c:control_plane|Control Plane]] status publication failure.
  - Required validation failure.
  - Unhandled exception in required runtime behavior.

The Node profile, script documentation, or validation procedure should define which errors count as recoverable for that Artifact. Developers should not make local assumptions about recoverability when the error affects shared [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline|Baseline]] behavior.

Recoverable errors should still produce logs, warnings, status updates, or [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]]. Non-recoverable errors should fail clearly and should not leave the Baseline appearing successful.

----

<WRAP centeralign>

© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.

</WRAP>