Repository navigation
expiry: clarify late expiry - #974
oliver-sanders wants to merge 1 commit into
Conversation
* Addresses cylc#699
* Addresses cylc/cylc-doc#974 * Add some text to the examples section explaining when expiry happens.
| Only :term:`active <active task>` waiting tasks can expire, submitted or | ||
| running tasks will not be killed, and tasks with a :term:`final status` will | ||
| not be removed if they pass their configured ``clock-expire`` time. |
There was a problem hiding this comment.
Maybe say expiry can only be detected in active waiting tasks. Other (future tasks) can expire, but they won't until they become active.
| Only :term:`active <active task>` waiting tasks can expire, submitted or | |
| running tasks will not be killed, and tasks with a :term:`final status` will | |
| not be removed if they pass their configured ``clock-expire`` time. | |
| Expiry can only be detected once a task has entered the active window of the | |
| workflow. Submitted, running, or final status tasks cannot expire (and will | |
| not be killed or removed if they pass their configured ``clock-expire`` time). |
There was a problem hiding this comment.
(It could also be noted that the purpose of expiry to is cancel a task before it runs, so in light of that purpose it is OK if expiry is detected "late" relative to the configured clock time, so long as it is detected before the task runs ... but I think that's been said elsewhere already).
There was a problem hiding this comment.
In Cylc 7 we had clock-trigger and clock-expire side-by-side, and both worked, kinda similarly. Due to SoS, the next instance of each task was spawned ahead of time, activating expiry detection.
With Cylc 8, expiry in future cycles is more adversely delayed by current cycles due to delayed spawning and as a result, this was once reported as a Cylc 8 migration issue.
As a result, in the optional output proposal, we added point 9 to document that expiry events are not instantaneous - the issue got lost for a while, I picked it up last week: https://cylc.github.io/cylc-admin/proposal-optional-output-extension.html#proposal
Example Cylc 7 use cases might look like this:
# poll for live data
get_live_data
# fallback to archive data after the expire time
# (we don't want this to wait longer than necessary)
get_live_data:expired => get_archive_data
# carry on
get_live_data | get_archive_data => run
# for this example to make sense standalone
get_live_data[-P1D] => get_live_dataWith Cylc 8, the way to achieve this would likely be to use a clock-trigger to detect expiry, rather than a clock-expire:
get_live_data[-P1D] => get_live_data
@live_data_expiry => !get_live_data & get_archive_data
get_live_data => !get_archive_data
get_live_data | get_archive_data => run
Addresses #699
There was already a note in this documentation section, so not much to do here, but have clarified / corrected the text slightly.
Goes with cylc/cylc-flow#7505
Requirements check-list
CONTRIBUTING.mdand added my name as a Code Contributor.