Skip to content

fix(blueprint): retain scheduled planning failures - #9234

Open
jcamargos wants to merge 2 commits into
apache:mainfrom
jcamargos:codex/blueprint-plan-failure
Open

jcamargos wants to merge 2 commits into
apache:mainfrom
jcamargos:codex/blueprint-plan-failure

Conversation

@jcamargos

@jcamargos jcamargos commented Oct 18, 2026 •

Copy link
Copy Markdown

Summary

A scheduled blueprint whose source plugin fails during plan generation currently leaves only a log entry: no pipeline is created, so pipeline history and status notifications miss the failed attempt.

Record these attempts as terminal FAILED pipelines with the original planning error, timestamps, blueprint identity, sync policy, priority, and labels. Persist the pipeline and labels in one transaction without creating tasks or entering the execution queue. Notify through the existing notification service only after commit. Storage and notification failures are logged without replacing the original planning error.

Manual triggers still return planning errors directly without creating history. Empty-plan handling and normal pipeline creation retain their existing behavior. The UI offers task reruns only when a terminal pipeline has tasks, and gives the action an accessible name. The developer manual documents recovery: correct the blueprint/connection and trigger a new run, since a planning failure has no tasks to rerun.

Does this close any open issues?

Fixes #9232.

Screenshots

The terminal-pipeline rerun button is hidden when totalTasks is zero. The planning error and recovery instructions remain visible. Ten component tests cover the zero-task states, error visibility, and successful rerun interactions for pipelines with tasks.

Other Information

Validation on Linux with Go 1.26.9 and the repository's generated mocks:

  • The new TestBlueprintJobRecordsPlanFailure regression test fails against the original production files at ee0079ab32d4a80220c9369f899120a98db8db34 (using a Go overlay), because neither persistence nor notification occurs.
  • go test -count=1 ./server/services with both database DSNs enabled (MySQL 8.4 and PostgreSQL 17), including the full service unit suite and the database regression test.
  • go vet ./server/services
  • golangci-lint v2.14.0 with the repository configuration over ./server/services/... ./core/models/... ./impls/dalgorm/...
  • yarn test src/routes/pipeline/components/info.test.tsx: 10 passing component tests.
  • yarn exec tsc --noEmit and ESLint on both changed UI files.
  • git diff --check

Regression coverage includes committed terminal records, notification failure, pipeline/label/commit/rollback errors, missing labels, the public manual-trigger path, empty-plan handling, successful creation, pending pipelines, and insertion failure.

No database migration or API schema change is required. Unit tests use mocked DAL/notification interfaces. A separate opt-in database regression test validates persisted history, labels, empty plans, timestamps, zero tasks, pending-queue exclusion, and rollback after a real duplicate-label insert failure on MySQL and PostgreSQL. See backend/test/Readme.md for reproducible commands. Full browser end-to-end tests were not run. Notifications retain the existing delivery semantics. The UI hides the task-rerun action for records without tasks; the persisted error message directs users to trigger a new blueprint run.
Suggested labels: pr-type/bug-fix, component/framework. GitHub rejected applying these labels because the contributor account does not have label permissions in this repository.

Signed-off-by: Jose Camargo <aml.camargo@hotmail.com>
Signed-off-by: Jose Camargo <aml.camargo@hotmail.com>
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.

[Bug][Blueprint] Scheduled run fails silently when plan generation errors

1 participant