Summary
When the fault manager cannot reach its storage, a client cannot tell that apart from "no faults".
ListFaults.srv has no error field, so the handler answers with an empty list. The services that do have an error field answer success=false, and the gateway turns any answered success=false into 404 Fault not found (ros2_medkit_gateway/src/http/handlers/fault_handlers.cpp:224), so a storage outage reads as a missing fault.
There is also no way to ask the fault manager how it is doing. With a PostgreSQL backend the node keeps running while the server is unreachable, so a node that is up says nothing about whether its faults are readable.
Proposed solution (optional)
Two parts.
-
ListFaults.srv gets a result field, the same shape the other fault services use (success plus error_message). The gateway maps a storage outage to 503 Service unavailable, which the handler already supports (fault_handlers.cpp:228), and keeps 404 for a fault that really is not there.
-
A status service on the fault manager: which storage backend is configured, whether it is connected, the reason of the last failed connection, and which startup work was skipped (the near-miss trim and the HEALED reclassification are skipped when the storage is unreachable at startup). The gateway reports that status in /health, so an operator sees a degraded fault manager without asking the node directly.
Additional context (optional)
The PostgreSQL backend (PR 651 and the draft PR 693) is what makes this visible: the node now starts and keeps serving while the server is unreachable, and answers Fault storage unavailable on every service that can carry an error. ListFaults and /health are the two places where that state is still invisible.
Summary
When the fault manager cannot reach its storage, a client cannot tell that apart from "no faults".
ListFaults.srvhas no error field, so the handler answers with an empty list. The services that do have an error field answersuccess=false, and the gateway turns any answeredsuccess=falseinto 404Fault not found(ros2_medkit_gateway/src/http/handlers/fault_handlers.cpp:224), so a storage outage reads as a missing fault.There is also no way to ask the fault manager how it is doing. With a PostgreSQL backend the node keeps running while the server is unreachable, so a node that is up says nothing about whether its faults are readable.
Proposed solution (optional)
Two parts.
ListFaults.srvgets a result field, the same shape the other fault services use (successpluserror_message). The gateway maps a storage outage to 503Service unavailable, which the handler already supports (fault_handlers.cpp:228), and keeps 404 for a fault that really is not there.A status service on the fault manager: which storage backend is configured, whether it is connected, the reason of the last failed connection, and which startup work was skipped (the near-miss trim and the HEALED reclassification are skipped when the storage is unreachable at startup). The gateway reports that status in
/health, so an operator sees a degraded fault manager without asking the node directly.Additional context (optional)
The PostgreSQL backend (PR 651 and the draft PR 693) is what makes this visible: the node now starts and keeps serving while the server is unreachable, and answers
Fault storage unavailableon every service that can carry an error.ListFaultsand/healthare the two places where that state is still invisible.