Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 5 additions & 4 deletions src/user-guide/writing-workflows/scheduling.rst
Original file line number Diff line number Diff line change
Expand Up @@ -1548,11 +1548,12 @@ In this example:

So, in the cycle ``2000-01-01T00:00Z``:

* ``foo`` would expire at ``2000-01-01T00:00Z``.
* ``bar`` would expire at ``2000-01-01T01:00Z``.
* ``foo`` would have an expiry time of 2000-01-01T**00**:00Z.
* ``bar`` would have an expiry time of 2000-01-01T**01**:00Z.

Only waiting tasks can expire, :term:`active tasks <active task>` will not be
killed if they pass their configured ``clock-expire`` time.
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.
Comment on lines +1554 to +1556

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe say expiry can only be detected in active waiting tasks. Other (future tasks) can expire, but they won't until they become active.

Suggested change
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).

@hjoliver hjoliver Oct 5, 2026 •

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(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).

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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_data

With 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


When a task expires, it produces the ``expired`` :term:`output`.
This can be used to
Expand Down
Loading