Should Stop

This node checks if the flow execution should be halted. Its output is determined by whether a higher-priority Trigger or Schedule has been activated while the robot is executing the current flow. Though the running flow remains unaffected, the "Should Stop" node will return 'true' in such instances. The decision to either stop or continue the flow, post this check, is left to the discretion of the developer.

Common Properties

• Name - The custom name of the node.
• Color - The custom color of the node.
• Delay Before (sec) - Waits in seconds before executing the node.
• Delay After (sec) - Waits in seconds after executing node.
• Continue On Error - Automation will continue regardless of any error. The default value is false.

info

if ContinueOnError property is true, no error is caught when the project is executed even if Catch node is used.

Output

• Should Stop - A boolean variable that is set externally, to indicate whether the workflow should stop or not.

Once the specific value of this variable is set externally, this node will check the value of the variable and determine whether to stop the flow execution or not. The node will output a boolean variable indicating whether the workflow execution should be stopped or not.

How It Works

The Should Stop node provides a graceful way to check if execution should be interrupted:

1. The node is called during flow execution
2. It queries the runtime to check if a stop signal has been set
3. The stop signal is typically set when:
   • A higher-priority Trigger is activated
   • A higher-priority Schedule starts
   • An external stop request is received
4. The node outputs a boolean value (true if should stop, false otherwise)
5. The flow developer can then use decision nodes to handle the stop gracefully
6. The current flow continues running unless explicitly stopped

Requirements

• None - this node works out of the box
• Typically used with decision nodes to act on the result

Error Handling

Error Code	Description	Solution
Core.Flow.ShouldStop.ErrOnCreate	Failed to parse node configuration	Verify node configuration is valid JSON
Core.Flow.ShouldStop.OnMessage	Message parsing failed during execution	Check that input message format is valid
Core.Flow.ShouldStop.OutputMarshal	Failed to serialize output message	Check message structure is valid

Usage Examples

Example 1: Graceful Loop Interruption

Check periodically in a long-running loop:

[Label: "LoopStart"]
    ↓
[Should Stop] → Output: shouldStop
    ↓
[Decision: if shouldStop == true]
    ↓ (yes)
    [Log: "Gracefully stopping due to higher priority task"]
    ↓
    [Save Progress]
    ↓
    [Stop: Success]
    ↓ (no)
[Process Next Item]
    ↓
[Go To: "LoopStart"]

Example 2: Long-Running Data Processing

Check between batch operations:

[Process Batch 1]
    ↓
[Should Stop]
    ↓
[If shouldStop: Save state and exit]
[Else: Continue]
    ↓
[Process Batch 2]
    ↓
[Should Stop]
    ↓
[If shouldStop: Save state and exit]
[Else: Continue]

Example 3: Priority-Based Task Management

Allow important tasks to preempt less important ones:

[Start Low Priority Task]
    ↓
[Process Item 1]
    ↓
[Should Stop] → (High priority trigger activated)
    ↓
[If shouldStop == true]
    ↓
    [Log: "Pausing low priority task for high priority"]
    ↓
    [Save current position]
    ↓
    [Stop: Success]

Usage Notes

• When Continue On Error is enabled, errors are not caught even if a Catch node is present
• The Should Stop check does not automatically stop the flow - you must implement the stop logic
• The current flow keeps running even when Should Stop returns true unless you explicitly stop it
• This is useful for cooperative multitasking where lower priority tasks yield to higher priority ones
• The stop signal is set externally by the Robomotion runtime when priorities dictate
• Use this node in long-running workflows to allow interruption
• Should Stop returns immediately - it's a lightweight check

Tips

• Place Should Stop nodes at natural checkpoints in your workflow (e.g., between major steps, inside loops)
• Always act on the result - don't check and ignore
• Save progress/state before stopping to allow resuming later
• Use with loops that process many items - check every N iterations
• Combine with decision nodes to implement graceful shutdown logic
• Log when stopping due to Should Stop for debugging and audit trails
• Consider saving partial results before stopping
• Test with multiple triggers of different priorities to ensure proper behavior
• Don't check Should Stop too frequently - it adds overhead
• Use Stop node with "Success" status when yielding to higher priority tasks

Related Nodes

• Stop - For actually terminating the flow
• Log - For logging stop decisions
• Label - For creating resumable checkpoints
• Go To - For implementing retry or resume logic