Repository navigation
Conversation
Signed-off-by: Jose Camargo <aml.camargo@hotmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
FAILEDpipelines 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 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
Not applicable: no frontend changes.
Other Information
Validation on Linux with Go 1.26.9 and the repository's generated mocks:
TestBlueprintJobRecordsPlanFailureregression test fails against the original production files atee0079ab32d4a80220c9369f899120a98db8db34(using a Go overlay), because neither persistence nor notification occurs.go test -race -count=1 ./server/services ./core/models ./impls/dalgormgo vet ./server/services ./core/models ./impls/dalgormgolangci-lintv2.14.0 with the repository configuration over./server/services/... ./core/models/... ./impls/dalgorm/...git diff --checkRegression 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. Tests use mocked DAL/notification interfaces; live MySQL/PostgreSQL and browser end-to-end tests were not run. Notifications retain the existing delivery semantics. Existing UI task-rerun controls cannot regenerate an absent plan; 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.