Skip to content

task_events_mgr: task events should not be able to re-wind task state.#7288

Open
oliver-sanders wants to merge 1 commit into
cylc:8.6.xfrom
oliver-sanders:7269
Open

task_events_mgr: task events should not be able to re-wind task state.#7288
oliver-sanders wants to merge 1 commit into
cylc:8.6.xfrom
oliver-sanders:7269

Conversation

@oliver-sanders

Copy link
Copy Markdown
Member

This fixes the bug, however, it does so by reverting a long-standing behaviour introduced in #2638 (we've been doing it this way ever since we dropped the poll-to-confirm approach).

I'm not sure why we would want to allow task state to re-wind in the event of FLAG_POLLED but not FLAG_RECEIVED, FLAG_INTERNAL might make sense, however, due to implied task state changes, the message will already have been processed and the children spawned, so it's not clear that this logic was required in any case?

Check List

  • I have read CONTRIBUTING.md and added my name as a Code Contributor.
  • Contains logically grouped changes (else tidy your branch by rebase).
  • Does not contain off-topic changes (use other PRs for other changes).
  • Applied any dependency changes to both setup.cfg (and conda-environment.yml if present).
  • Tests are included (or explain why tests are not needed).
  • Changelog entry included if this is a change that can affect users
  • Cylc-Doc pull request opened if required at cylc/cylc-doc/pull/XXXX.
  • If this is a bug fix, PR should be raised against the relevant ?.?.x branch.

@oliver-sanders oliver-sanders added this to the 8.6.4 milestone Apr 28, 2026
@oliver-sanders oliver-sanders self-assigned this Apr 28, 2026
@oliver-sanders oliver-sanders added the bug Something is wrong :( label Apr 28, 2026
@oliver-sanders oliver-sanders marked this pull request as draft April 28, 2026 09:34
* Closes cylc#7269
* This fixes a bug where a delayed poll notification could cause a
  final-state task to re-wind to submitted/running.
@oliver-sanders oliver-sanders marked this pull request as ready for review April 28, 2026 11:55
@MetRonnie MetRonnie linked an issue Apr 29, 2026 that may be closed by this pull request

@MetRonnie MetRonnie left a comment

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.

From my understanding, if process_message() returns True (indicating an attempt at a backwards state change) then the scheduler will poll the task to confirm. By removing the check for FLAG_RECEIVED is there now the potential for an endless polling loop where the poll always tries to take the task to an earlier state? (It seems unlikely to happen though)

In any case I think this poll to confirm is now useless and ought to be removed?

if self.task_events_mgr.process_message(
itask, tm.severity, tm.message, tm.event_time,
self.task_events_mgr.FLAG_RECEIVED, tm.job_id.submit_num
):
should_poll = True
if should_poll:
to_poll_tasks.append(itask)
if to_poll_tasks:
self.task_job_mgr.poll_task_jobs(to_poll_tasks)

@oliver-sanders oliver-sanders modified the milestones: 8.6.4, 8.6.x May 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something is wrong :(

Projects

None yet

Development

Successfully merging this pull request may close these issues.

data store: task state regression from delayed poll response

2 participants