You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The custom trigger "my-trigger" gets stored along with the "my-message" task message that generated it.
Skip mode messages
Skip mode is no different, we still have to store the task outputs, however, the task messages don't make much sense here as they were internally generated.
E.G. The message "my-message" shouldn't really be in the DB if the task was run in skip mode because it doesn't make sense.
Skip mode prerequisites
In the proposal we agreed on this:
When tasks are run in skip mode, the prerequisites which correspond to the outputs they generate should be marked as satisfied by skip mode rather than satisfied naturally for provenance reasons.
For the purpose of cylc remove logic, satisfied by skip mode should be treated the same as satisfied naturally.
Proposal / Question
Extend this prerequisite logic to cover task messages.
I.E. The task message for any output satisfied by skip mode should be recorded as "satisfied by skip mode".
$ cylc vip -N .
$ sqlite3 ~/cylc-run/tmp.PQ7h6sdpgP/runN/.service/db 'SELECT * FROM task_outputs;'1|foo|[1]|{"submitted": "satisfied by skip mode", "started": "satisfied by skip mode", "satisfied by skip mode": "succeeded", "my-trigger": "satisfied by skip mode"}
This would also extend to the other non-live modes (dummy & simulation).
This change would be visible in the GUI:
The text was updated successfully, but these errors were encountered:
Extension to #6039 and https://github.com/cylc/cylc-admin/blob/master/docs/proposal-skip-mode.md#proposal-skip-run-mode-for-tasks
Task outputs in the DB
When tasks are run, we store any messages and outputs they generated into the
task_outputs
table in the database.E.G:
The custom trigger "my-trigger" gets stored along with the "my-message" task message that generated it.
Skip mode messages
Skip mode is no different, we still have to store the task outputs, however, the task messages don't make much sense here as they were internally generated.
E.G. The message "my-message" shouldn't really be in the DB if the task was run in skip mode because it doesn't make sense.
Skip mode prerequisites
In the proposal we agreed on this:
Proposal / Question
Extend this prerequisite logic to cover task messages.
I.E. The task message for any output satisfied by skip mode should be recorded as "satisfied by skip mode".
This would also extend to the other non-live modes (dummy & simulation).
This change would be visible in the GUI:
The text was updated successfully, but these errors were encountered: