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
164 lines
8.6 KiB
Gherkin
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
|