mirror of
https://github.com/corda/corda.git
synced 2024-12-18 20:47:57 +00:00
[DOCS] - Clarify behaviour of hospital in unhandled errors (#5366)
This commit is contained in:
parent
98329444f5
commit
132244c437
@ -6,13 +6,14 @@ Overview
|
||||
|
||||
The **flow hospital** refers to a built-in node service that manages flows that have encountered an error.
|
||||
|
||||
This service is responsible for recording, tracking, diagnosing, recovering and retrying. It determines whether errored flows should be retried
|
||||
This service is responsible for recording, tracking, diagnosing, recovering and retrying flows. It determines whether errored flows should be retried
|
||||
from their previous checkpoints or have their errors propagate. Flows may be recoverable under certain scenarios (eg. manual intervention
|
||||
may be required to install a missing contract JAR version). For a given errored flow, the flow hospital service determines the next course of
|
||||
action towards recovery and retry.
|
||||
|
||||
.. note:: The flow hospital will never terminate a flow, but will propagate its error back to the state machine, and ultimately, end user code to handle
|
||||
if it ultimately proves impossible to resolve automatically.
|
||||
.. note:: If the raised exception cannot be handled from the hospital, it will be propagated to the application code.
|
||||
If the exception is not handled by the application code either, then the flow will terminate and any records of it will be removed from the hospital.
|
||||
Below, you can find a list of the errors that are handled by the hospital.
|
||||
|
||||
This concept is analogous to *exception management handling* associated with enterprise workflow software, or
|
||||
*retry queues/stores* in enterprise messaging middleware for recovering from failure to deliver a message.
|
||||
|
Loading…
Reference in New Issue
Block a user