As per the question. Can I, programatticaly within a task, tell whether the task was triggered by a person manually (CLI or UI), or whether Cylc triggered it itself?
The information is semi available, I’m not aware of a shortcut provided in the task environment. Without such a shortcut you’d have to work it out from log files, which is possible, but risky.
Why do you want the task to be aware of how it was triggered?
An untried sketch approach which is compex, fragile and probably not a good idea. I might be able to offer a better alternative if we knew why you are trying to do this.
You should be able to out from the scheduler log whether this instance of the task has been force triggered.
$ grep force_trigger "$CYLC_WORKFLOW_RUN_DIR/log/scheduler/log"
INFO - Command "force_trigger_tasks" received. ID=cffe0637-2905-4c50-b743-40cc49775014
force_trigger_tasks(flow=['all'], flow_wait=False, tasks=['1574/foo'])
INFO - Command "force_trigger_tasks" actioned. ID=cffe0637-2905-4c50-b743-40cc49775014
$ grep taskname "$CYLC_WORKFLOW_RUN_DIR/log/scheduler/log"
2024-10-16T08:48:21+01:00 INFO - [1574/foo:waiting(runahead)] => waiting
2024-10-16T08:48:21+01:00 INFO - [1574/foo:waiting] => waiting(queued)
2024-10-16T08:48:21+01:00 INFO - [1574/foo:waiting(queued)] => waiting
2024-10-16T08:48:21+01:00 INFO - [1574/foo:waiting] => preparing
2024-10-16T08:48:23+01:00 INFO - [1574/foo/01:preparing] submitted to localhost:background[390854]
2024-10-16T08:48:23+01:00 INFO - [1574/foo/01:preparing] => submitted
2024-10-16T08:48:25+01:00 INFO - [1574/foo/01:submitted] => running
2024-10-16T08:48:26+01:00 INFO - [1574/foo/01:running] => failed
2024-10-16T08:48:26+01:00 WARNING - [1574/foo/01:failed] did not complete the required outputs:
* 1574/foo did not complete the required outputs:
force_trigger_tasks(flow=['all'], flow_wait=False, tasks=['1574/foo'])
2024-10-16T08:48:47+01:00 INFO - [1574/foo/01:failed] => waiting
If you can find the line that shows tasks have been force triggered with a later timestamp that any evidence of it running normally then you can say it’s been force triggered.
I’m not sure I want to be able to. I was just thinking about tasks using rose bunch and only retry non-complete items. Rd retry has failed multiple times and a user wants to run it to try again, it feels likely they world want to start from scratch. Similarly, I wonder if someone triggering a new flow would prefer rose bunch to run things again or not.
If the workflow has stalled because of the incomplete bunch task you can just pass the --flow=new argument to restart the rose bunch task from the start. After it’s finished the new flow will just merge with the existing stalled flow(s).
This question will become somewhat ill-defined soon, due to a change to allow manual triggering of a group of tasks such that internal (in-group) dependencies are respected but external (out-group) ones get force-satisfied.
Then, it’s only the initial tasks of the group’s sub-graph(s) that are entirely manually triggered.