A workflow with 3 tasks is run. The tasks all have dependencies set.
If the first task does not find a file, the next tasks are blocked and ended. A post-process calls a script to cancel and deactivate the workflow.
In the process monitoring perspective, the workflow shows the status ENDED_CANCEL - manually canceled.
Go to the workflow executions and it shows as ENDED_CANCEL - manually canceled. Open the workflow from executions, and in the workflow monitor, the first task is green as if it is still active.
Release : 21.0.4
This is related to how the deactivation works.
The customer is doing a forced deactivation of the workflow.
During a normal deactivation, if a job inside the workflow is running, it is not possible to deactivate it.
During normal deactivation, the statuses in context of the workflow (EJPP) table is copied in to the AJPP (history records). In workflows which do finish normally these are most of times ENDED_OK or
ENDED_NOT_OK.
What's now happening is that the first job is still running due to the processing of the postprocess (status in EH is 1574)
The Deactivation (forced) is triggered via the postprocessing and the current status from the EJPP is moved into the AJPP and deleted after
The postcondition processing finishes, the job finishes and is deactivated and removed from the EH table, and the correct values copied in the AH table.
When a Workflow is deactivated further 'updates' are not propagated to the AJPP table, so although the job finished correctly, this does not propagate.
The Workflow monitor, on the other side, loads the information from the AJPP table for the runid which show that the job is still 'running', and that is why it's displayed.
Either do not to forced deactivate during post-processing (WF logic change) or ignore this.