CoreRasurae
f2f7aa5dc9
Implement multiple Stage A/B/E/SEC milestones for the v3 lifecycle system: - Stage A5.3+A5.4: Add LifecycleActionModel and LifecyclePlanModel SQLAlchemy models with to_domain()/from_domain() conversion methods - Stage A5.6: Implement ActionRepository with full CRUD, namespace/state queries, referential integrity checks, and retry decorator - Stage E1: Add subplan domain models (ExecutionMode, SubplanMergeStrategy, SubplanConfig, SubplanStatus, SubplanAttempt, SubplanFailureHandler) with computed properties on Plan (is_subplan, is_root_plan, depth, has_subplans) - Stage A6: Add AutomationLevel enum (MANUAL, REVIEW_BEFORE_APPLY, FULL_AUTOMATION), settings integration, PlanLifecycleService auto-progression, pause/resume, and CLI commands (--automation-level, set-automation-level) - Stage SEC1: Remove eval()/exec() from stream_router.py, replace with named operation and transform registries; code blocks and unregistered transforms now raise StreamRoutingError - Add langchain-anthropic dependency - Update BDD tests for security changes and relax ADR directory requirement
164 lines
7.3 KiB
Gherkin
164 lines
7.3 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 a plan that was created independently
|
|
Then the plan should not be recognized as a subplan
|
|
|
|
@subplan_hierarchy
|
|
Scenario: A plan spawned by another plan is a subplan
|
|
Given a plan that was spawned by another plan
|
|
Then the plan should be recognized as a subplan
|
|
|
|
@subplan_hierarchy
|
|
Scenario: A plan with no designated root is considered the root
|
|
Given a plan with no designated root
|
|
Then the plan should be recognized as a root plan
|
|
|
|
@subplan_hierarchy
|
|
Scenario: A plan whose root is itself is considered the root
|
|
Given a plan whose designated root is itself
|
|
Then the plan should be recognized as a root plan
|
|
|
|
@subplan_hierarchy
|
|
Scenario: A plan whose root is a different plan is not the root
|
|
Given a plan whose designated root is a different plan
|
|
Then the plan should not be recognized as a root plan
|
|
|
|
@subplan_hierarchy
|
|
Scenario: A root plan reports a depth of zero
|
|
Given a plan with no designated root
|
|
Then the plan hierarchy depth should be 0
|
|
|
|
@subplan_hierarchy
|
|
Scenario: A non-root plan reports a placeholder depth
|
|
Given a plan whose designated root is a different plan
|
|
Then the plan hierarchy depth should be -1
|
|
|
|
@subplan_hierarchy
|
|
Scenario: A plan with no child work has no subplans
|
|
Given a plan that has no child work tracked
|
|
Then the plan should report having no subplans
|
|
|
|
@subplan_hierarchy
|
|
Scenario: A plan with tracked child work has subplans
|
|
Given a plan that has tracked child work
|
|
Then the plan should report having subplans
|
|
|
|
@failure_handler
|
|
Scenario: The failure handler halts remaining work when fail-fast is enabled
|
|
Given a subplan configuration with fail-fast enabled and parallel work
|
|
And a subplan that has failed
|
|
When the failure handler evaluates whether to halt remaining work
|
|
Then the remaining work should be halted
|
|
|
|
@failure_handler
|
|
Scenario: The failure handler halts remaining work for sequential execution
|
|
Given a subplan configuration with fail-fast disabled and sequential work
|
|
And a subplan that has failed
|
|
When the failure handler evaluates whether to halt remaining work
|
|
Then the remaining work should be halted
|
|
|
|
@failure_handler
|
|
Scenario: The failure handler allows remaining work for parallel execution without fail-fast
|
|
Given a subplan configuration with fail-fast disabled and parallel work
|
|
And a subplan that has failed
|
|
When the failure handler evaluates whether to halt remaining work
|
|
Then the remaining work should continue
|
|
|
|
@failure_handler
|
|
Scenario: The failure handler allows remaining work for dependency-ordered execution without fail-fast
|
|
Given a subplan configuration with fail-fast disabled and dependency-ordered work
|
|
And a subplan that has failed
|
|
When the failure handler evaluates whether to halt remaining work
|
|
Then the remaining work should continue
|
|
|
|
@failure_handler
|
|
Scenario: The failure handler does not retry when retries are disabled
|
|
Given a subplan configuration with retries disabled
|
|
And a subplan that failed with error "ValidationError occurred"
|
|
When the failure handler evaluates whether to retry the failed work
|
|
Then the failed work should not be retried
|
|
|
|
@failure_handler
|
|
Scenario: The failure handler does not retry when all attempts are exhausted
|
|
Given a subplan configuration allowing up to 2 retries
|
|
And a subplan on attempt 3 that failed with error "TimeoutError"
|
|
When the failure handler evaluates whether to retry the failed work
|
|
Then the failed work should not be retried
|
|
|
|
@failure_handler
|
|
Scenario: A configuration error is not eligible for retry
|
|
Given a subplan configuration allowing up to 3 retries
|
|
And a subplan on attempt 1 that failed with error "ConfigurationError: bad config"
|
|
When the failure handler evaluates whether to retry the failed work
|
|
Then the failed work should not be retried
|
|
|
|
@failure_handler
|
|
Scenario: An authentication error is not eligible for retry
|
|
Given a subplan configuration allowing up to 3 retries
|
|
And a subplan on attempt 1 that failed with error "AuthenticationError: invalid token"
|
|
When the failure handler evaluates whether to retry the failed work
|
|
Then the failed work should not be retried
|
|
|
|
@failure_handler
|
|
Scenario: A missing resource error is not eligible for retry
|
|
Given a subplan configuration allowing up to 3 retries
|
|
And a subplan on attempt 1 that failed with error "MissingResourceError: file not found"
|
|
When the failure handler evaluates whether to retry the failed work
|
|
Then the failed work should not be retried
|
|
|
|
@failure_handler
|
|
Scenario: A circular dependency error is not eligible for retry
|
|
Given a subplan configuration allowing up to 3 retries
|
|
And a subplan on attempt 1 that failed with error "CircularDependencyError: cycle detected"
|
|
When the failure handler evaluates whether to retry the failed work
|
|
Then the failed work should not be retried
|
|
|
|
@failure_handler
|
|
Scenario: A validation error is eligible for retry
|
|
Given a subplan configuration allowing up to 3 retries
|
|
And a subplan on attempt 1 that failed with error "ValidationError: schema mismatch"
|
|
When the failure handler evaluates whether to retry the failed work
|
|
Then the failed work should be retried
|
|
|
|
@failure_handler
|
|
Scenario: A timeout error is eligible for retry
|
|
Given a subplan configuration allowing up to 3 retries
|
|
And a subplan on attempt 1 that failed with error "TimeoutError: deadline exceeded"
|
|
When the failure handler evaluates whether to retry the failed work
|
|
Then the failed work should be retried
|
|
|
|
@failure_handler
|
|
Scenario: A temporary resource error is eligible for retry
|
|
Given a subplan configuration allowing up to 3 retries
|
|
And a subplan on attempt 1 that failed with error "TemporaryResourceError: service unavailable"
|
|
When the failure handler evaluates whether to retry the failed work
|
|
Then the failed work should be retried
|
|
|
|
@failure_handler
|
|
Scenario: A merge conflict error is eligible for retry
|
|
Given a subplan configuration allowing up to 3 retries
|
|
And a subplan on attempt 1 that failed with error "MergeConflictError: conflicting changes"
|
|
When the failure handler evaluates whether to retry the failed work
|
|
Then the failed work should be retried
|
|
|
|
@failure_handler
|
|
Scenario: An unrecognized error type is not eligible for retry
|
|
Given a subplan configuration allowing up to 3 retries
|
|
And a subplan on attempt 1 that failed with error "SomeUnknownError: unexpected"
|
|
When the failure handler evaluates whether to retry the failed work
|
|
Then the failed work should not be retried
|
|
|
|
@failure_handler
|
|
Scenario: A failure with no error message is not eligible for retry
|
|
Given a subplan configuration allowing up to 3 retries
|
|
And a subplan on attempt 1 that failed with no error message
|
|
When the failure handler evaluates whether to retry the failed work
|
|
Then the failed work should not be retried
|