Change default execution/trigging behavior

[poautran]

In GitLab by @woutdenolf on Nov 18, 2025, 15:42 GMT+1:

After discussions with the EPDAK developers at MPIKG, we would like to revise the default execution/propagation logic.

Currently, tasks can be executed without propagating results downstream, but in practice we have no use case for “execute only.” Whenever an upstream task runs, its results should always be made available to downstream tasks via dynamic inputs.

Therefore, I propose that:

Execution should always be followed by propagation to downstream tasks (i.e., “execute + propagate”),

But propagation should not automatically continue further downstream unless this is "enabled" by the receiving node.

The receiving widgets should decide whether they want to automatically “execute + propagate” when they receive new upstream data (after dynamic inputs have been updated).

If possible, it would be useful to add a context-menu option (right-click on a node in the canvas) to enable or disable automatic execution for that node.

This would give users control over whether a node executes immediately upon receiving new inputs or waits for a manual trigger.

Migrated from GitLab: https://gitlab.esrf.fr/workflow/ewoks/ewoksorange/-/issues/72

[poautran]

In GitLab by @woutdenolf on Nov 18, 2025, 15:42 GMT+1:

changed title from Change default execute behavior to Change default execution/trigging behavior

[poautran]

In GitLab by @woutdenolf on Nov 18, 2025, 15:50 GMT+1:

FYI EPDAK, Est, Tomwer etc. already have their own implementation of this but the idea is to support it in the base widget.

[poautran]

In GitLab by @woutdenolf on Nov 18, 2025, 15:50 GMT+1:

Ping @payno @Retegan @Thomas18

[poautran]

In GitLab by @payno on Nov 18, 2025, 16:31 GMT+1:

I am not 100% sure fully understand the use cases.

I think we have one use case that should be considered: processing and waiting for user feedback before propagating.

For example in tomography we have a task that search the Center Of Rotation (CoR) of a dataset.
Users might need to trigger several time this task with different settings before validating it and propagate the value downstream.
This is not really a fancy use case for interactive workflows. Will this still be possible ?

[poautran]

In GitLab by @woutdenolf on Nov 19, 2025, 09:08 GMT+1:

I think we have one use case that should be considered: processing and waiting for user feedback before propagating.

The idea would be that the data is always propagated but does not necessarily cause downstream execution (so only sets the dynamic values). But maybe there are reasons you don't always want this? For example when the Ewoks task inputs are shown in the widget as well, setting dynamic values will update the widget.

[poautran]

In GitLab by @woutdenolf on Nov 19, 2025, 09:15 GMT+1:

Essentially this is the flow when everything would trigger automatically

execute node 1 -> update widget 1
               -> set dynamic values of node 2 -> update widget 2
                                               -> execute node 2 -> update widget 2
                                                                 -> set dynamic values of node 2 -> ...

Then we need the option for some of these arrow to not be automatic. Currently this is only "-> set dynamic values of node X". To proposal would be to have it on "-> execute node X". But maybe we need all three arrow types to be configurable (auto=True/False).