- About UiPath Assistant
- UiPath Assistant on Mac
- Field Descriptions
- Automation Configuration
- Task Capture Launcher
- Assistant Governance
- UiPath Assistant for Excel add-in
- About Backward and Forward Compatibility
- Hardware and Software Requirements
- Updating the Robot
- Setting Up Windows Server for High-Density Robots
- Services the Robot Connects to
- UiPath.Settings File Description
- Restarting Robot Components
- Windows Sessions
- Login Using Thales Luna Credential System
- Login Using NShield Key Storage Provider
- Redirecting Robots Through a Proxy Server
- Executing Tasks in a Minimized RDP Window
- Using Mapped Network Drives
- Stopping a Process
- Disable Stop Button
- Custom Package Folders and Network Paths
- CrowdStrike Integration
- Robot Citrix Apps Virtualization
- Common Connection Errors
- Unresponsive Robot Over RDP
- Duplicate Execution Logs
- Frequently Encountered Robot Errors
- Increased Process Execution Duration
- Enforced Package Signature Verification
- Message Too Large to Process
- Errors When Running as Administrator
- NuGet Packages Not Accessible After Migration
- User Access Control Prompt and UI Automation Activities
- .NET required during installation
- Assembly Cannot Be Loaded From Network Or Azure File Share
- Activities cannot find .NET Runtime
Stopping a Process
A process can either be stopped through Soft Stop or Kill commands.
Soft Stop command
The Soft Stop command marks the process in a should stop state. This state can be queried from the still executing workflow using the Should Stop activity. The workflow should explicitly handle this state and finish. The workflow does not automatically stop without handling the should stop state. See REFramework for a scenario that leverages Soft Stop.
The Stop command is designed for unattended automations and is available only in Orchestrator. In Orchestrator, the Soft Stop command is named Stop.
The Kill command first sends a Cancel request to the workflow. The workflow Cancel request is distinct from should stop.Cancel is a workflow signal that is automatically handled by the workflow. The signal causes the activities to cancel in cascade while allowing Finally blocks of the workflow to execute clean-up steps. If the Cancel signal does not stop the workflow in three seconds, the job is killed by forcibly stopping any running activities at any point in their execution.
The Kill command is designed for attended automations and is available in Orchestrator and in desktop clients and APIs such as Assistant,Studio,RobotJS. In Desktop clients, the Kill command is named Stop.
The REFramework Process Scenario
REFramework leverages the Soft Stop command.
When a process is stopped, the block containing the error logic is skipped and the final block is executed. This causes the
values for the
SystemError to stay
null and the overall process status is considered successful. The behavior described is intended.
During a Try-Catch workflow, when a process is stopped, the transaction status can show as successful when it actually did not complete.
Cancelling a Process
If the execution is in the Try or Catch block when the Cancel command is received by the Robot, it skips to the Finally block which checks for any errors. If no errors are found, then the Finally block thinks the execution completed successfully as there are no failure events (they are blank).
Killing a Process
If the execution is in the Try or Catch block when the Kill command is received by the Robot, it first tries to Cancel the process, skipping to the Finally block. If the logic inside the Finally block is not finished in three seconds since receiving the Cancel command, the whole execution is killed and the overall process is successful in the logs as no errors were recorded in the Catch block since it was skipped.
Avoiding False Positives
- Setting the Process status to
Successfulshould be done only inside the Try block, after the Business Logic is completed.
- Setting the status to
Failedshould be done only inside the Catch block, after the error handling logic is completed.
- In the Finally block, there should be only cleanup logic present, since it is executed no matter if the execution was successful or not.
Ensure error logic is executed
If the block that contains the error logic is skipped, the values for
null and the overall process status is considered
successful, as no errors were recorded.