freemo
583e6b7ea2
CI / benchmark-publish (pull_request) Has been skipped
CI / lint (pull_request) Successful in 14s
CI / build (pull_request) Successful in 16s
CI / quality (pull_request) Successful in 17s
CI / security (pull_request) Successful in 36s
CI / typecheck (pull_request) Successful in 54s
CI / unit_tests (pull_request) Successful in 2m39s
CI / integration_tests (pull_request) Successful in 3m10s
CI / docker (pull_request) Successful in 40s
CI / coverage (pull_request) Successful in 5m0s
CI / lint (push) Successful in 14s
CI / build (push) Successful in 15s
CI / quality (push) Successful in 16s
CI / security (push) Successful in 34s
CI / typecheck (push) Successful in 35s
CI / benchmark-regression (push) Has been skipped
CI / unit_tests (push) Successful in 2m23s
CI / docker (push) Successful in 38s
CI / integration_tests (push) Successful in 3m8s
CI / coverage (push) Successful in 5m10s
CI / benchmark-publish (push) Successful in 16m26s
CI / benchmark-regression (pull_request) Successful in 30m12s
Implement spec-mandated Layer 4 Predictive Error Prevention system: - ErrorPattern domain model with pattern text, historical failures, preventive checks, frequency tracking, and keyword-based matching. - ErrorPatternRepository with in-memory CRUD + context-matching query. - ErrorPatternService with record_failure(), match_patterns(), and get_statistics() methods. - Wire into plan execution via plan_lifecycle_service pre-execution hook. - Add error pattern statistics to CLI diagnostics output. Behave BDD: 11 scenarios covering recording, matching, formatting, stats. Robot Framework: 3 integration smoke tests. ASV benchmarks: pattern matching performance. ISSUES CLOSED: #571
75 lines
3.6 KiB
Gherkin
75 lines
3.6 KiB
Gherkin
@coverage_boost
|
|
Feature: System diagnostics uncovered code paths
|
|
As a developer ensuring thorough test coverage
|
|
I want to exercise uncovered diagnostic check paths in system.py
|
|
So that stale-lock, async-worker, error-pattern, and file-permission edge cases are tested
|
|
|
|
# ===========================================================================
|
|
# _check_file_permissions — line 344: writable-but-not-readable data dir
|
|
# ===========================================================================
|
|
|
|
Scenario: File permissions check on data dir that is writable but not readable
|
|
Given a sysdiag test environment
|
|
And a data dir that exists
|
|
When I run the file permissions check with read access denied
|
|
Then the sysdiag check status should be "warn"
|
|
And the sysdiag check details should be "data dir w"
|
|
|
|
Scenario: File permissions check on data dir that is neither readable nor writable
|
|
Given a sysdiag test environment
|
|
And a data dir that exists
|
|
When I run the file permissions check with no access at all
|
|
Then the sysdiag check status should be "error"
|
|
And the sysdiag check details should be "data dir no access"
|
|
|
|
# ===========================================================================
|
|
# _check_stale_locks — lines 367-388
|
|
# ===========================================================================
|
|
|
|
Scenario: Stale locks check finds zero stale locks in existing table
|
|
Given a sysdiag test environment
|
|
When I run the stale locks check with 0 stale locks in the table
|
|
Then the sysdiag check status should be "ok"
|
|
And the sysdiag check details should be "0 stale locks"
|
|
|
|
Scenario: Stale locks check finds stale locks present
|
|
Given a sysdiag test environment
|
|
When I run the stale locks check with 3 stale locks in the table
|
|
Then the sysdiag check status should be "warn"
|
|
And the sysdiag check details should contain "3 stale lock(s) found"
|
|
And the sysdiag check should have a recommendation
|
|
|
|
Scenario: Stale locks check handles database errors gracefully
|
|
Given a sysdiag test environment
|
|
When I run the stale locks check with a database error
|
|
Then the sysdiag check status should be "warn"
|
|
And the sysdiag check details should be "unable to check"
|
|
|
|
# ===========================================================================
|
|
# _check_async_worker_health — lines 405-417
|
|
# ===========================================================================
|
|
|
|
Scenario: Async worker health check when async is enabled
|
|
Given a sysdiag test environment
|
|
When I run the async worker health check with async enabled
|
|
Then the sysdiag check status should be "ok"
|
|
And the sysdiag check details should contain "enabled"
|
|
And the sysdiag check details should contain "max_workers="
|
|
And the sysdiag check details should contain "poll_interval="
|
|
|
|
Scenario: Async worker health check handles settings errors gracefully
|
|
Given a sysdiag test environment
|
|
When I run the async worker health check with a settings error
|
|
Then the sysdiag check status should be "warn"
|
|
And the sysdiag check details should be "unable to check"
|
|
|
|
# ===========================================================================
|
|
# _check_error_patterns — lines 438-442
|
|
# ===========================================================================
|
|
|
|
Scenario: Error pattern check when service initialization fails
|
|
Given a sysdiag test environment
|
|
When I run the error patterns check with a service error
|
|
Then the sysdiag check status should be "ok"
|
|
And the sysdiag check details should be "empty (no patterns recorded)"
|