Skip to content

Disable the retention scheduler in the remaining app-booting test suites - #50

Merged
CountableNewt merged 1 commit into
devfrom
test/retention-scheduler-remaining-suites
Sep 30, 2026
Merged

CountableNewt merged 1 commit into
devfrom
test/retention-scheduler-remaining-suites

Conversation

@CountableNewt

Copy link
Copy Markdown
Collaborator

Follow-up to #49, which fixed the same race in McpToolNamingTests.

The race

Every suite that calls configure(app) registers SkillUsageRetentionLifecycle, whose didBootAsync spawns a detached task running SkillUsageService.prune immediately. Its per-project DELETEs take a write lock on the same shared in-memory SQLite database the suite is writing to, which is the intermittent database is locked failure.

These five suites boot the app without the guard: ApiKeyRevocationTests, McpOAuthTests, McpPingRouteTests, SecurityFindingMitigationTests, SkillRuntimeHardeningTests.

Why per-suite rather than one gate

Gating the lifecycle on application.environment == .testing would have fixed all six suites in one line, and that was my first instinct. But AdminAnalyticsRollupLifecycle explicitly documents that its scheduler runs "including Vapor --env testing (staging APIs)" — so .testing is a real deploy target in this codebase, not a test-only marker, and gating on it would change staging behaviour. This follows the existing per-suite DISABLE_SKILL_USAGE_RETENTION_SCHEDULER=1 convention already used by SkillUsageRouteTests and SkillUsageAnalyticsTests.

Two suites take the flag through a caller-supplied env dictionary, so it is layered on inside the helper rather than threaded through every call site.

Verification

Full suite as CI runs it — swift test --enable-swift-testing --disable-xctest --no-parallel -Xswiftc -warnings-as-errors: 216 tests in 32 suites passed, no warnings.

Still outstanding

AdminAnalyticsRollupLifecycle also refreshes at boot and writes, so it is the same class of race; scripts/ci.sh disables it for CI, but a bare local swift test does not. Left alone here to keep this diff to the reported issue.

🤖 Generated with Claude Code

…ites

Every suite that calls `configure(app)` gets a detached `SkillUsageService.prune`
at boot, whose per-project DELETEs can lock the shared in-memory SQLite database
the suite is writing to. McpToolNamingTests hit this intermittently; these five
suites carry the same race.

Gating the lifecycle on `.testing` would have fixed all of them at once, but
AdminAnalyticsRollupLifecycle documents that schedulers are expected to run under
`--env testing` for staging, so this follows the existing per-suite convention
instead.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@CountableNewt
CountableNewt merged commit a368ac8 into dev Sep 30, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant