# Can a task tell if it was triggered by Cylc or by a user? **URL:** \ **Category:** Cylc Support\ **Created:** [October 16, 2024, 5:57am UTC](https://cylc.discourse.group/t/can-a-task-tell-if-it-was-triggered-by-cylc-or-by-a-user/1040 "2024-10-16T05:57:06Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![TomC](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/tomc/32/115_2.png) [@TomC](https://cylc.discourse.group/u/TomC)\ **Post date:** [October 16, 2024, 5:57am UTC](https://cylc.discourse.group/t/can-a-task-tell-if-it-was-triggered-by-cylc-or-by-a-user/1040/1 "2024-10-16T05:57:06Z")
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? ---
**Author:** ![wxtim](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/wxtim/32/151_2.png) [@wxtim](https://cylc.discourse.group/u/wxtim)\ **Post date:** [October 16, 2024, 8:12am UTC](https://cylc.discourse.group/t/can-a-task-tell-if-it-was-triggered-by-cylc-or-by-a-user/1040/2 "2024-10-16T08:12:28Z")
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. > > ```shell > $ 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. ---
**Author:** ![TomC](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/tomc/32/115_2.png) [@TomC](https://cylc.discourse.group/u/TomC)\ **Post date:** [October 16, 2024, 8:37am UTC](https://cylc.discourse.group/t/can-a-task-tell-if-it-was-triggered-by-cylc-or-by-a-user/1040/3 "2024-10-16T08:37:19Z")
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. ---
**Author:** ![wxtim](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/wxtim/32/151_2.png) [@wxtim](https://cylc.discourse.group/u/wxtim)\ **Post date:** [October 16, 2024, 8:44am UTC](https://cylc.discourse.group/t/can-a-task-tell-if-it-was-triggered-by-cylc-or-by-a-user/1040/4 "2024-10-16T08:44:29Z")
Docs say > If the task is run again as part of a new flow (e.g. `--flow=new`), then all commands will be re-run. _[rose docs - built in apps - rose bunch](https://metomi.github.io/rose/doc/html/api/built-in/rose_bunch.html#incremental-mode-in-cylc-tasks)_ 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). ---
**Author:** ![hilary.j.oliver](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/hilary.j.oliver/32/4_2.png) [@hilary.j.oliver](https://cylc.discourse.group/u/hilary.j.oliver)\ **Post date:** [October 16, 2024, 10:11pm UTC](https://cylc.discourse.group/t/can-a-task-tell-if-it-was-triggered-by-cylc-or-by-a-user/1040/5 "2024-10-16T22:11:12Z")
> [@TomC](#): > > 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? 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. > > > Implement group trigger proposal: https://github.com/cylc/cylc-admin/pull/197 > > … > (Not approved yet, but it's a clear winner and a relatively small change, and I wanted to finish coding it up - after initial experiments - while still fresh in the brain). > > On current master: > \- on triggering one or more tasks: run them all immediately regardless of prerequisites. > > On this branch: > \- on triggering one or more tasks, satisfy any off-group (aka off-flow) prerequisites > > Result: we can trigger a sub-graph "naturally" by specifying all of its member tasks: > \- tasks with only off-group prerequisites will trigger immediately > \- the subsequent flow will respect in-group prerequisites > \- no stalling due to unsatisfied off-group prerequisites > > This provides an alternative, easier for some cases, to triggering just the initial task(s) of the sub-graph and setting off-flow prerequisites (if any) manually. > > > \----- > > \#### example > > \`\`\`cylc > \[scheduler\] > allow implicit tasks = True > \[scheduling\] > \[\[graph\]\] > R1 = """ > foo =\> a =\> b =\> c =\> bar > off =\> b > """ > \[runtime\] > \[\[root\]\] > pre-script = sleep 4 > \[\[bar\]\] > script = "test $CYLC\_TASK\_SUBMIT\_NUMBER != 1" > \`\`\` > Run it and wait for \`bar\` to fail and stall the workflow. > > \`\`\`bash > $ cylc trigger grp //1/a //1/b //1/c --flow=new > # 1/a runs immediately in flow 2 - its only prerequisite (foo =\> a) is off-group > # 1/b gets its off-group prerequisite satisfied (off =\> b) and spawns to wait on in-group (a =\> b) > # flow 2 traverses a =\> b =\> c, then flows on to merge with and run bar to complete the workflow > \`\`\` > > \------ > > \#### caveats? > > Triggering a future sub-graph, or a past sub-graph with \`--flow=new\`, is safe and easy. > > But triggering a past sub-graph in the original flow comes with a gotcha: setting off-group prerequisites spawns the target task to wait on other prerequisites, which aren't going to get satisfied when the original flow does not re-traverse the graph. > > This isn't technically incorrect. The exact same thing would happen if we attempted to trigger the same past sub-graph the spawn-on-demand "native" way in the same flow: trigger the initial task and set the off-flow prerequisite. > > But maybe we can do something to mitigate the problem if users try to do this. > > \----- > > \#### interaction with the upcoming \`cylc remove\` extension > > On this branch now, to re-run a \*past\* sub-graph you have to use \`--flow=new\`. > > After the \`remove\` extension we'll be able to erase the flow history and re-run a past sub-graph in the original flow. We may want to add an option to \`cylc trigger\` to do that automatically, or even make it the default. > > \------- > > \#### interaction with upcoming inactive task matching developments > > We can't trigger a group of inactive tasks by family name or glob yet, but that's a general problem, not specific to this branch. > > \------- > > \