freemo
051ee7c290
CI / benchmark-publish (pull_request) Has been skipped
CI / lint (pull_request) Successful in 21s
CI / quality (pull_request) Successful in 31s
CI / typecheck (pull_request) Successful in 47s
CI / security (pull_request) Successful in 52s
CI / build (pull_request) Successful in 56s
CI / e2e_tests (pull_request) Successful in 5m1s
CI / integration_tests (pull_request) Successful in 5m30s
CI / unit_tests (pull_request) Successful in 5m42s
CI / docker (pull_request) Successful in 58s
CI / coverage (pull_request) Successful in 7m35s
CI / build (push) Successful in 21s
CI / docker (push) Has been skipped
CI / benchmark-regression (pull_request) Failing after 49m24s
CI / lint (push) Successful in 22s
CI / quality (push) Successful in 39s
CI / security (push) Successful in 48s
CI / typecheck (push) Successful in 1m26s
CI / benchmark-regression (push) Has been skipped
CI / e2e_tests (push) Successful in 5m53s
CI / coverage (push) Successful in 9m4s
CI / benchmark-publish (push) Successful in 19m10s
CI / integration_tests (push) Failing after 19m18s
CI / unit_tests (push) Failing after 19m20s
Added 52 new .feature files and corresponding _steps.py files targeting previously uncovered code paths in the following areas: - TUI layer: app, commands, persona (state/schema/registry), widgets, input (shell_exec, reference_parser) - Application services: plan lifecycle/service/executor, session, project, repo indexing, correction, checkpoint, actor, llm_actors, strategy coordinator, resource file watcher, service retry wiring - CLI commands: session, resource, repl, plan, db, automation_profile - Domain models: retry_policy, resource_type, cost_budget, docker_compose_analyzer, detail_level, _sql_string_aware, _postgresql_helpers - Core: circuit_breaker, retry_service_patterns - Infrastructure: repositories, transaction_sandbox, strategy_registry, plugins/loader, container - Config: settings - Agents: plan_generation, context_analysis, auto_debug - A2A: facade All new tests follow the Behave/Gherkin BDD standard. Resolved step definition collisions with unique prefixes. Fixed Alembic fileConfig logger disabling issue (disable_existing_loggers=False). ISSUES CLOSED: #1068
150 lines
8.2 KiB
Gherkin
150 lines
8.2 KiB
Gherkin
Feature: Retry Policy Model Coverage
|
|
Scenarios that exercise uncovered code paths in the
|
|
retry_policy.py domain model — validators, registry overrides,
|
|
and edge-case error handling.
|
|
|
|
Background:
|
|
Given the retry policy model module is imported
|
|
|
|
# ------------------------------------------------------------------
|
|
# CircuitBreakerConfig validator: cooldown_seconds > recovery_timeout
|
|
# (lines 228-232)
|
|
# ------------------------------------------------------------------
|
|
Scenario: CircuitBreakerConfig rejects cooldown exceeding recovery timeout
|
|
When I create a CircuitBreakerConfig with cooldown 120 and recovery timeout 60
|
|
Then a ValueError should be raised mentioning cooldown and recovery_timeout
|
|
|
|
# ------------------------------------------------------------------
|
|
# ServiceRetryPolicy validator: invisible Unicode control chars
|
|
# (lines 268-269)
|
|
# ------------------------------------------------------------------
|
|
Scenario: ServiceRetryPolicy rejects service name with zero-width space
|
|
When I create a ServiceRetryPolicy with a zero-width-space in the name
|
|
Then a ValidationError should be raised mentioning invisible Unicode
|
|
|
|
Scenario: ServiceRetryPolicy rejects service name with RTL override character
|
|
When I create a ServiceRetryPolicy with an RTL override character in the name
|
|
Then a ValidationError should be raised mentioning invisible Unicode
|
|
|
|
# ------------------------------------------------------------------
|
|
# apply_overrides: unknown top-level keys warning (lines 556-560)
|
|
# ------------------------------------------------------------------
|
|
Scenario: Registry apply_overrides warns on unknown override keys
|
|
Given a fresh ServiceRetryPolicyRegistry
|
|
When I apply overrides with unknown keys for service "plan_service"
|
|
Then the unknown keys should be silently ignored
|
|
And the policy for "plan_service" should still be valid
|
|
|
|
# ------------------------------------------------------------------
|
|
# apply_overrides: invalid service name (lines 566-572)
|
|
# ------------------------------------------------------------------
|
|
Scenario: Registry apply_overrides skips empty service name
|
|
Given a fresh ServiceRetryPolicyRegistry
|
|
When I apply overrides with an empty-string service name
|
|
Then the override should be skipped without crashing
|
|
|
|
Scenario: Registry apply_overrides skips service name that is only whitespace
|
|
Given a fresh ServiceRetryPolicyRegistry
|
|
When I apply overrides with a whitespace-only service name
|
|
Then the override should be skipped without crashing
|
|
|
|
# ------------------------------------------------------------------
|
|
# apply_overrides: non-dict sub-key for retry / circuit_breaker
|
|
# (lines 579-581)
|
|
# ------------------------------------------------------------------
|
|
Scenario: Registry apply_overrides warns on non-dict retry sub-key
|
|
Given a fresh ServiceRetryPolicyRegistry
|
|
When I apply overrides where "retry" value is a string instead of dict
|
|
Then the non-dict retry sub-key should be ignored
|
|
And the policy for "plan_service" should still be valid
|
|
|
|
Scenario: Registry apply_overrides warns on non-dict circuit_breaker sub-key
|
|
Given a fresh ServiceRetryPolicyRegistry
|
|
When I apply overrides where "circuit_breaker" value is an integer
|
|
Then the non-dict circuit_breaker sub-key should be ignored
|
|
And the policy for "plan_service" should still be valid
|
|
|
|
# ------------------------------------------------------------------
|
|
# apply_overrides: final ValidationError from invalid merged policy
|
|
# (lines 600-607)
|
|
# ------------------------------------------------------------------
|
|
Scenario: Registry apply_overrides skips override that produces invalid merged policy
|
|
Given a fresh ServiceRetryPolicyRegistry
|
|
When I apply overrides with an invalid retry max_attempts of -5
|
|
Then the invalid merged override should be skipped
|
|
And the policy for "plan_service" should retain its original max_attempts
|
|
|
|
# ------------------------------------------------------------------
|
|
# apply_overrides: non-dict override_data for a service (line 546-552)
|
|
# ------------------------------------------------------------------
|
|
Scenario: Registry apply_overrides ignores non-dict override data
|
|
Given a fresh ServiceRetryPolicyRegistry
|
|
When I apply overrides where the override data is a string
|
|
Then the non-dict override data should be ignored
|
|
|
|
# ------------------------------------------------------------------
|
|
# Combined: override with both unknown keys and valid changes
|
|
# ------------------------------------------------------------------
|
|
Scenario: Registry apply_overrides processes valid keys despite unknown keys
|
|
Given a fresh ServiceRetryPolicyRegistry
|
|
When I apply overrides with unknown keys and a valid description change for "plan_service"
|
|
Then the description for "plan_service" should be updated
|
|
And the unknown keys should not appear in the policy
|
|
|
|
# ------------------------------------------------------------------
|
|
# CircuitBreakerConfig: edge case cooldown equals recovery (valid)
|
|
# ------------------------------------------------------------------
|
|
Scenario: CircuitBreakerConfig accepts cooldown equal to recovery timeout
|
|
When I create a CircuitBreakerConfig with cooldown 60 and recovery timeout 60
|
|
Then the CircuitBreakerConfig should be created successfully
|
|
|
|
# ------------------------------------------------------------------
|
|
# apply_overrides: override retry_category scalar merge (line 593-594)
|
|
# ------------------------------------------------------------------
|
|
Scenario: Registry apply_overrides can change retry_category via scalar merge
|
|
Given a fresh ServiceRetryPolicyRegistry
|
|
When I apply overrides changing retry_category to "network" for "plan_service"
|
|
Then the retry_category for "plan_service" should be "network"
|
|
|
|
# ------------------------------------------------------------------
|
|
# RetryPolicyConfig validator: max_delay < base_delay (lines 159-163)
|
|
# ------------------------------------------------------------------
|
|
Scenario: RetryPolicyConfig rejects max_delay less than base_delay
|
|
When I create a RetryPolicyConfig with base_delay 10 and max_delay 5
|
|
Then a ValueError should be raised mentioning max_delay and base_delay
|
|
|
|
# ------------------------------------------------------------------
|
|
# Registry.get auto-generates default for unknown service (lines 496-497)
|
|
# ------------------------------------------------------------------
|
|
Scenario: Registry get auto-generates default policy for unknown service
|
|
Given a fresh ServiceRetryPolicyRegistry
|
|
When I get the policy for unknown service "brand_new_service"
|
|
Then a default policy should be returned for "brand_new_service"
|
|
And the auto-generated policy should have the database retry category
|
|
|
|
# ------------------------------------------------------------------
|
|
# Registry.register stores a deep copy of a policy (lines 510-511)
|
|
# ------------------------------------------------------------------
|
|
Scenario: Registry register stores and retrieves a custom policy
|
|
Given a fresh ServiceRetryPolicyRegistry
|
|
When I register a custom policy for service "custom_svc" with max_attempts 7
|
|
Then the registry should return a policy for "custom_svc" with max_attempts 7
|
|
|
|
# ------------------------------------------------------------------
|
|
# Registry.all_policies returns snapshot of all policies (lines 618-619)
|
|
# ------------------------------------------------------------------
|
|
Scenario: Registry all_policies returns snapshot of all registered policies
|
|
Given a fresh ServiceRetryPolicyRegistry
|
|
When I request all policies from the registry
|
|
Then the snapshot should contain all default service policies
|
|
And the snapshot should be a deep copy not sharing identity
|
|
|
|
# ------------------------------------------------------------------
|
|
# Registry.registered_services returns sorted list (lines 628-629)
|
|
# ------------------------------------------------------------------
|
|
Scenario: Registry registered_services returns sorted list of service names
|
|
Given a fresh ServiceRetryPolicyRegistry
|
|
When I request the registered services list
|
|
Then rpmcov the list should be sorted alphabetically
|
|
And the list should contain the default service names
|