Understanding and resolving the Presumed Interrupted flow state<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: block; max-width: ; width: auto; height: auto; } } For the latest information, see Flow execution details About the Presumed Interrupted state Previously, when a flow execution is unexpectedly interrupted, the flow context state remained "In Progress". This is misleading to the user. Unexpected interruptions can occur when a transaction terminates or a node restarts. The new Presumed Interrupted state in the sys_flow_context table helps identify interrupted flow runs. This state doesn't mean the flow is canceled—it may still be running or it could resume later. This state lets you know that a flow is long-running and appears stuck. Possible causes include: Node restarts or infinite loops within the flowThis flow triggered another business rule or flow Beginning with the Utah release, flows can be paused and resumed when a node is shutting down or restarting with the Graceful Shutdown feature: This feature does not cover flow executions that are interrupted while running on the MID ServerThis feature does not trigger flow error handling. It's designed to allow flows to resume when possible. How it works Two new columns have been added to sys_flow_context: transaction and claimed_by. When the flow engine begins working on a flow context: the sys_flow_context.claimed_by field is set to the node idthe sys_flow_context.transaction field is set to the sys_id of the current transaction If the flow run is sent to the MID Server, the claimed_by field is set to mid and the transaction field remains empty. Any flow context suspected to be interrupted has its state changed to Presumed Interrupted. The system logs an error message that begins with: 'Flow state changed from IN_PROGRESS to PRESUMED_INTERRUPTED due to inactivity...' At configured intervals, the system checks the sys_flow_context table for flow runs that appear to be interrupted. The system performs two types of checks: The this node check runs every 15 minutes and looks for any flow context that meets the following criteria: Claimed by the corrent nodeHas an IN_PROGRESS or CONTINUE_SYNC stateWas last updated more than 15 minutes priorHas a transaction ID that is no longer valid for the current node The other nodes check runs every hour and handles cases where a flow run is interrupted during node shutdown and the node isn't restarted. It looks for any flow context that meets the following criteria: Claimed by a different nodeHas an IN_PROGRESS or CONTINUE_SYNC stateLast updated more than eight hours prior The transaction id can not be checked since valid transaction ids are only available for a running node. Note: If a flow step (such as a script) runs for more than eight hours, the system might incorrectly mark it as Presumed Interrupted. If this happens, the state reverts to the expected value when the step completes. How to resolve Presumed Interrupted flows Check if the transaction (sys_flow_context.transaction) is still active on the node (sys_flow_context.claimed_by). If active: The flow is likely in an infinite loop (caused by a problematic script or looping condition)Cancel the flowRefactor the flow and run it again If not active: The current node has been restarted or an unknown error occurred that was not properly handledManually complete the remainder of the flow from where the flow run was stoppedCreate a subflow from the point of interruption. For example, if the flow has 10 steps and it stopped at step 5, create a subflow that includes steps 5 through 10 only. Local host logs can help identify if a node was shut down or restarted using the following command: egrep “glide Loading platform|Initiating normal shutdown” localhost_log.2019-0*.txt Configurable system properties The Presumed Interrupted flow state feature uses these configurable system properties: PropertyDescriptionDefault Valuecom.glide.hub.flow.interrupted_flow_marker.enabledEnables or disables the featuretruecom.glide.hub.flow.interrupted_flow_marker.this_node.updated_sec_agoMinimum time since last update for "this node" check900 seconds (15 minutes)com.glide.hub.flow.interrupted_flow_marker.other_nodes.updated_sec_agoMinimum time since last update for "other nodes" check28800 seconds (8 hours)