I am not sure if the following behaviour is intentional or a bug:
Stopping an orchestation-process-job (a process that is using the persistence package) via Orchestrator while that job is in the state Suspended or Resumed (in combination with an pending allocation) will not send the robot a stop signal that needs active checking (using the Should Stop activity) but it will stop/kill the job immediately.
This behaviour is similiar to when stopping a normal (non orchestration process) job which is also in the state Pending.
I do not believe that this behaviour is intentional, because it does not allow a proper controlled stop of an orchestation process.
I have an orchestration process, that is quite fast (since it is not using any UI activities). To properly stop the job from processing files I would have to time my Stop-Signal from orchestrator right in tiny time frame the bot needs between a Wait for X and Resume activity and the Should Stop activity (which might be virtually non existing).
And since Delay-Activities also do not work on orchestration processes I do not have the option to artificially increase this time frame.
So I have to requests/questions for you:
- Is the above described behavior intentional?
Should the Stop Job action in Orchestrator kill a suspended job immediately?
- If yes: What is the best practice to stop an orchestration process in a controlled matter?
- If no: I would like to report this as a bug!