Skip to content

refactor: introduce PipelineRun aggregate for runner-planner protocol#904

Merged
dieppa merged 1 commit into
release/1.3from
refactor/pipeline_run_execution_planner
May 12, 2026
Merged

refactor: introduce PipelineRun aggregate for runner-planner protocol#904
dieppa merged 1 commit into
release/1.3from
refactor/pipeline_run_execution_planner

Conversation

@dieppa
Copy link
Copy Markdown
Member

@dieppa dieppa commented May 12, 2026

Unify in-flight state and reporting under a single mutable aggregate (PipelineRun), removing
the parallel ExecutionResultBuilder bookkeeping the runner used alongside the planner.

New (internal.core.pipeline.run):

  • PipelineRun — aggregate root; one StageRun per stage, timing, and the single source
    of truth for ExecuteResponseData via toResponse(). Mutators go through
    markStageState(name, state, result?).
  • StageRun — per-stage holder: loaded stage + current state + optional StageResult.
    Package-private setters; only PipelineRun mutates.
  • StageState — polymorphic (NOT_STARTED / STARTED / COMPLETED / Failed); Failed
    carries the ErrorInfo. isFailed() / getErrorInfo() replace the previous
    enum + optional pairing.

Breaking API change for ExecutionPlanner implementors:

  • getNextExecution(List<AbstractLoadedStage>)getNextExecution(PipelineRun). Both
    CommunityExecutionPlanner and CloudExecutionPlanner migrated; bodies unchanged
    (they read loaded stages via pipelineRun.getLoadedStages()). Per-stage state
    consumption is deferred to a later phase.

Removed:

  • ExecutablePipeline — trivial wrapper; ExecutionPlan now holds
    List<ExecutableStage> directly and absorbs getExecutableStages() /
    isExecutionRequired().
  • ExecutionResultBuilder — its responsibilities (stage accumulation, timing,
    pipeline-level error) move onto PipelineRun; the response is produced by toResponse().

No observable behavior change: runner still fail-fasts on StageExecutionException;
response shape, event firing points, and payloads are identical to today. Unblocks the next
phase (stop fail-fasting across stages) by giving the runner one place to record outcomes
and one call to materialize the final report.

Replace the (List<AbstractLoadedStage>, ExecutionResultBuilder) pair carried through the runner
with a single mutable aggregate (PipelineRun) that owns in-flight state and produces the
ExecuteResponseData.

- New `internal.core.pipeline.run`: **PipelineRun**, **StageRun**, **StageState** (polymorphic;
  Failed carries ErrorInfo).
- API change: `ExecutionPlanner.getNextExecution(List<AbstractLoadedStage>)` →
  `getNextExecution(PipelineRun)`. CommunityExecutionPlanner and CloudExecutionPlanner migrated.
- Intent-named mutators: `markStageStarted`, `markStageCompleted(result)`,
  `markStageFailed(exception)` — aggregate derives ErrorInfo from StageExecutionException.
- Removed **ExecutablePipeline** (trivial wrapper) and **ExecutionResultBuilder**;
  ExecutionPlan holds `List<ExecutableStage>` directly; `PipelineRun.toResponse()` builds the
  report.

No observable behavior change: runner still fail-fasts on StageExecutionException; response
shape and event firing points are identical.
@dieppa dieppa force-pushed the refactor/pipeline_run_execution_planner branch from 46ed57f to 481d3aa Compare May 12, 2026 14:13
@dieppa dieppa merged commit 695f88f into release/1.3 May 12, 2026
4 checks passed
@dieppa dieppa deleted the refactor/pipeline_run_execution_planner branch May 12, 2026 14:39
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.

1 participant