Files
cleveragents-core/features/plan_model_uncovered_lines.feature
freemo ca1c341b18
CI / benchmark-publish (pull_request) Has been skipped
CI / lint (pull_request) Successful in 14s
CI / build (pull_request) Successful in 17s
CI / quality (pull_request) Successful in 19s
CI / security (pull_request) Successful in 28s
CI / typecheck (pull_request) Successful in 32s
CI / integration_tests (pull_request) Successful in 2m39s
CI / unit_tests (pull_request) Successful in 5m22s
CI / docker (pull_request) Successful in 38s
CI / benchmark-regression (pull_request) Successful in 17m47s
CI / coverage (pull_request) Successful in 19m6s
CI / lint (push) Successful in 14s
CI / build (push) Successful in 15s
CI / quality (push) Successful in 20s
CI / security (push) Successful in 29s
CI / typecheck (push) Successful in 36s
CI / benchmark-regression (push) Has been skipped
CI / integration_tests (push) Successful in 3m23s
CI / unit_tests (push) Successful in 9m12s
CI / docker (push) Successful in 16s
CI / benchmark-publish (push) Successful in 10m4s
CI / coverage (push) Successful in 19m27s
Tests: Significantly improved coverage of the unit tests
2026-02-22 00:43:08 -05:00

164 lines
8.6 KiB
Gherkin

@phase1 @domain @plan @subplan
Feature: Plan Hierarchy and Subplan Failure Handling
As a system operator
I want plans to correctly identify their position in a hierarchy
And I want the failure handler to make sound decisions about stopping and retrying
So that subplan orchestration behaves reliably under all conditions
@subplan_hierarchy
Scenario: A standalone plan is not considered a subplan
Given an uncovered-lines plan that was created independently
Then the uncovered-lines plan should not be recognized as a subplan
@subplan_hierarchy
Scenario: A plan spawned by another plan is a subplan
Given an uncovered-lines plan that was spawned by another plan
Then the uncovered-lines plan should be recognized as a subplan
@subplan_hierarchy
Scenario: A plan with no designated root is considered the root
Given an uncovered-lines plan with no designated root
Then the uncovered-lines plan should be recognized as a root plan
@subplan_hierarchy
Scenario: A plan whose root is itself is considered the root
Given an uncovered-lines plan whose designated root is itself
Then the uncovered-lines plan should be recognized as a root plan
@subplan_hierarchy
Scenario: A plan whose root is a different plan is not the root
Given an uncovered-lines plan whose designated root is a different plan
Then the uncovered-lines plan should not be recognized as a root plan
@subplan_hierarchy
Scenario: A root plan reports a depth of zero
Given an uncovered-lines plan with no designated root
Then the uncovered-lines plan hierarchy depth should be 0
@subplan_hierarchy
Scenario: A non-root plan reports a placeholder depth
Given an uncovered-lines plan whose designated root is a different plan
Then the uncovered-lines plan hierarchy depth should be -1
@subplan_hierarchy
Scenario: A plan with no child work has no subplans
Given an uncovered-lines plan that has no child work tracked
Then the uncovered-lines plan should report having no subplans
@subplan_hierarchy
Scenario: A plan with tracked child work has subplans
Given an uncovered-lines plan that has tracked child work
Then the uncovered-lines plan should report having subplans
@failure_handler
Scenario: The failure handler halts remaining work when fail-fast is enabled
Given an uncovered-lines subplan configuration with fail-fast enabled and parallel work
And an uncovered-lines subplan that has failed
When the uncovered-lines failure handler evaluates whether to halt remaining work
Then the uncovered-lines remaining work should be halted
@failure_handler
Scenario: The failure handler halts remaining work for sequential execution
Given an uncovered-lines subplan configuration with fail-fast disabled and sequential work
And an uncovered-lines subplan that has failed
When the uncovered-lines failure handler evaluates whether to halt remaining work
Then the uncovered-lines remaining work should be halted
@failure_handler
Scenario: The failure handler allows remaining work for parallel execution without fail-fast
Given an uncovered-lines subplan configuration with fail-fast disabled and parallel work
And an uncovered-lines subplan that has failed
When the uncovered-lines failure handler evaluates whether to halt remaining work
Then the uncovered-lines remaining work should continue
@failure_handler
Scenario: The failure handler allows remaining work for dependency-ordered execution without fail-fast
Given an uncovered-lines subplan configuration with fail-fast disabled and dependency-ordered work
And an uncovered-lines subplan that has failed
When the uncovered-lines failure handler evaluates whether to halt remaining work
Then the uncovered-lines remaining work should continue
@failure_handler
Scenario: The failure handler does not retry when retries are disabled
Given an uncovered-lines subplan configuration with retries disabled
And an uncovered-lines subplan that failed with error "ValidationError occurred"
When the uncovered-lines failure handler evaluates whether to retry the failed work
Then the uncovered-lines failed work should not be retried
@failure_handler
Scenario: The failure handler does not retry when all attempts are exhausted
Given an uncovered-lines subplan configuration allowing up to 2 retries
And an uncovered-lines subplan on attempt 3 that failed with error "TimeoutError"
When the uncovered-lines failure handler evaluates whether to retry the failed work
Then the uncovered-lines failed work should not be retried
@failure_handler
Scenario: A configuration error is not eligible for retry
Given an uncovered-lines subplan configuration allowing up to 3 retries
And an uncovered-lines subplan on attempt 1 that failed with error "ConfigurationError: bad config"
When the uncovered-lines failure handler evaluates whether to retry the failed work
Then the uncovered-lines failed work should not be retried
@failure_handler
Scenario: An authentication error is not eligible for retry
Given an uncovered-lines subplan configuration allowing up to 3 retries
And an uncovered-lines subplan on attempt 1 that failed with error "AuthenticationError: invalid token"
When the uncovered-lines failure handler evaluates whether to retry the failed work
Then the uncovered-lines failed work should not be retried
@failure_handler
Scenario: A missing resource error is not eligible for retry
Given an uncovered-lines subplan configuration allowing up to 3 retries
And an uncovered-lines subplan on attempt 1 that failed with error "MissingResourceError: file not found"
When the uncovered-lines failure handler evaluates whether to retry the failed work
Then the uncovered-lines failed work should not be retried
@failure_handler
Scenario: A circular dependency error is not eligible for retry
Given an uncovered-lines subplan configuration allowing up to 3 retries
And an uncovered-lines subplan on attempt 1 that failed with error "CircularDependencyError: cycle detected"
When the uncovered-lines failure handler evaluates whether to retry the failed work
Then the uncovered-lines failed work should not be retried
@failure_handler
Scenario: A validation error is eligible for retry
Given an uncovered-lines subplan configuration allowing up to 3 retries
And an uncovered-lines subplan on attempt 1 that failed with error "ValidationError: schema mismatch"
When the uncovered-lines failure handler evaluates whether to retry the failed work
Then the uncovered-lines failed work should be retried
@failure_handler
Scenario: A timeout error is eligible for retry
Given an uncovered-lines subplan configuration allowing up to 3 retries
And an uncovered-lines subplan on attempt 1 that failed with error "TimeoutError: deadline exceeded"
When the uncovered-lines failure handler evaluates whether to retry the failed work
Then the uncovered-lines failed work should be retried
@failure_handler
Scenario: A temporary resource error is eligible for retry
Given an uncovered-lines subplan configuration allowing up to 3 retries
And an uncovered-lines subplan on attempt 1 that failed with error "TemporaryResourceError: service unavailable"
When the uncovered-lines failure handler evaluates whether to retry the failed work
Then the uncovered-lines failed work should be retried
@failure_handler
Scenario: A merge conflict error is eligible for retry
Given an uncovered-lines subplan configuration allowing up to 3 retries
And an uncovered-lines subplan on attempt 1 that failed with error "MergeConflictError: conflicting changes"
When the uncovered-lines failure handler evaluates whether to retry the failed work
Then the uncovered-lines failed work should be retried
@failure_handler
Scenario: An unrecognized error type is not eligible for retry
Given an uncovered-lines subplan configuration allowing up to 3 retries
And an uncovered-lines subplan on attempt 1 that failed with error "SomeUnknownError: unexpected"
When the uncovered-lines failure handler evaluates whether to retry the failed work
Then the uncovered-lines failed work should not be retried
@failure_handler
Scenario: A failure with no error message is not eligible for retry
Given an uncovered-lines subplan configuration allowing up to 3 retries
And an uncovered-lines subplan on attempt 1 that failed with no error message
When the uncovered-lines failure handler evaluates whether to retry the failed work
Then the uncovered-lines failed work should not be retried