Skip to content

fix(scheduler): preserve stages on transition errors - #2215

Merged
milenkovicm merged 1 commit into
apache:mainfrom
QuakeWang:stage-transition-atomicity
Aug 3, 2026
Merged

fix(scheduler): preserve stages on transition errors#2215
milenkovicm merged 1 commit into
apache:mainfrom
QuakeWang:stage-transition-atomicity

Conversation

@QuakeWang

@QuakeWang QuakeWang commented Aug 1, 2026

Copy link
Copy Markdown
Member

Which issue does this PR close?

Closes #2214

Rationale for this change

StaticExecutionGraph removed a stage before running fallible plan transformations. If a transformation failed, the error returned before the stage was reinserted, leaving the execution graph without the original stage.

What changes are included in this PR?

Build replacement stages before updating the stage map, so failed resolve and rollback transitions preserve the original stage. Add regression tests for all three affected transitions.

Are there any user-facing changes?

No API changes. On a failed running-stage rollback, the original stage and its running-task tracking are preserved, but the error still propagates before a CancelTasks event can be produced.

Testing

  • ci/scripts/rust_fmt.sh
  • Scheduler all-targets/all-features Clippy
  • Scheduler library tests

Build replacement stages before updating the execution graph so failed plan rewrites leave the original stage intact. Add regression coverage for resolve and rollback transitions.

Signed-off-by: QuakeWang <wangfuzheng0814@foxmail.com>

@sandugood sandugood left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Nicely done, thanks @QuakeWang. Added a comment

stage_id,
ExecutionStage::UnResolved(stage.to_unresolved(failure_reasons)?),
);
let unresolved_stage = stage.to_unresolved(failure_reasons)?;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

When this errors, the running_tasks was already collected, but it is now discarded. Better than a vanished stage, but it's a distinct bad state. Maybe add a line to "Are there any user facing changes"?

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.

Good point. The running-task list was also discarded on this error path before this PR, but preserving the stage makes the resulting behavior worth stating explicitly: the stage remains Running, its task tracking is retained, and the error propagates before a CancelTasks event can be emitted. I have clarified this in the user-facing changes section. Changing cancellation or recovery policy would be outside the failure-atomic transition scope of this PR.

@milenkovicm milenkovicm left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

thanks @QuakeWang this make sense to me

@milenkovicm
milenkovicm merged commit 6e9ff68 into apache:main Aug 3, 2026
23 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

StaticExecutionGraph drops stages when plan transformations fail

3 participants