HAL9000
2778bde95a
CI / benchmark-publish (pull_request) Has been skipped
CI / helm (pull_request) Successful in 40s
CI / build (pull_request) Successful in 58s
CI / lint (pull_request) Successful in 1m3s
CI / typecheck (pull_request) Successful in 1m25s
CI / quality (pull_request) Successful in 1m26s
CI / security (pull_request) Successful in 1m35s
CI / benchmark-regression (pull_request) Failing after 51s
CI / push-validation (pull_request) Successful in 20s
CI / integration_tests (pull_request) Successful in 3m30s
CI / e2e_tests (pull_request) Successful in 4m13s
CI / unit_tests (pull_request) Successful in 7m2s
CI / docker (pull_request) Successful in 1m48s
CI / coverage (pull_request) Successful in 11m25s
CI / status-check (push) Blocked by required conditions
CI / benchmark-publish (push) Has started running
CI / status-check (pull_request) Successful in 3s
CI / benchmark-regression (push) Has been skipped
CI / helm (push) Successful in 44s
CI / push-validation (push) Successful in 55s
CI / build (push) Successful in 1m35s
CI / quality (push) Successful in 1m57s
CI / lint (push) Successful in 2m9s
CI / typecheck (push) Successful in 2m28s
CI / security (push) Successful in 2m34s
CI / integration_tests (push) Successful in 5m33s
CI / unit_tests (push) Successful in 6m7s
CI / e2e_tests (push) Successful in 6m41s
CI / coverage (push) Has started running
CI / docker (push) Successful in 1m33s
ISSUES CLOSED: #7501
44 lines
2.4 KiB
Gherkin
44 lines
2.4 KiB
Gherkin
@tdd_issue @tdd_issue_7501
|
|
Feature: TDD Issue #7501 — PlanResult.success derived from result_success column
|
|
As a system operator managing plan lifecycle
|
|
I want PlanResult.success to be derived from the dedicated result_success column
|
|
So that plans with historical build errors are not incorrectly marked as failed
|
|
|
|
The root cause is that PlanRepository._to_domain derived PlanResult.success
|
|
from `error_message is None`. Because error_message is shared between the
|
|
build phase and the result phase, a plan that had a build error but later
|
|
succeeded in the apply phase would be incorrectly reconstructed as failed.
|
|
|
|
The fix adds a dedicated result_success column to the plans table and updates
|
|
_to_domain to use it. For backward compatibility, when result_success is NULL
|
|
(pre-migration records), the legacy heuristic (error_message is None) is used.
|
|
|
|
Background:
|
|
Given a clean in-memory database for plan result success tests
|
|
And a legacy plan repository backed by the database
|
|
|
|
Scenario: Plan with result_success=True is reconstructed as success=True
|
|
Given a legacy plan with applied_at set and result_success column True
|
|
When the legacy plan is retrieved from the repository
|
|
Then the retrieved plan result success should be True
|
|
|
|
Scenario: Plan with result_success=False is reconstructed as success=False
|
|
Given a legacy plan with applied_at set and result_success column False
|
|
When the legacy plan is retrieved from the repository
|
|
Then the retrieved plan result success should be False
|
|
|
|
Scenario: Plan with build error but result_success=True is reconstructed as success=True
|
|
Given a legacy plan with a build error_message and result_success column True
|
|
When the legacy plan is retrieved from the repository
|
|
Then the retrieved plan result success should be True
|
|
|
|
Scenario: Plan with NULL result_success falls back to error_message heuristic when no error
|
|
Given a legacy plan with applied_at set and result_success column NULL and no error_message
|
|
When the legacy plan is retrieved from the repository
|
|
Then the retrieved plan result success should be True
|
|
|
|
Scenario: Plan with NULL result_success falls back to error_message heuristic when error present
|
|
Given a legacy plan with applied_at set and result_success column NULL and an error_message
|
|
When the legacy plan is retrieved from the repository
|
|
Then the retrieved plan result success should be False
|