Skip to content

test(api-cache): fix flaky cleanup-expired test under coverage instrumentation - #671

Open
fro-bot wants to merge 1 commit into
mainfrom
fro-bot/fix-flaky-api-cache-test
Open

test(api-cache): fix flaky cleanup-expired test under coverage instrumentation#671
fro-bot wants to merge 1 commit into
mainfrom
fro-bot/fix-flaky-api-cache-test

Conversation

@fro-bot

@fro-bot fro-bot commented Jul 10, 2026

Copy link
Copy Markdown
Collaborator

What

pnpm test:coverage was intermittently failing on test/scripts/api-cache.test.ts > API Cache > Cache Management > should cleanup only expired entries with expected 3 to be 2. pnpm test (no coverage) passed reliably.

Root cause

The test used a 100ms default TTL for all three cache entries, including the "fresh" entry that's expected to survive cleanupExpired(). Under v8 coverage instrumentation overhead, the gap between adding the fresh entry and calling cleanupExpired() could exceed 100ms, causing it to expire too (removedEntries: 3 instead of 2).

Fix

Give the "fresh" entry a long custom TTL (60s) via the existing set(url, data, ttlMs) override, so it can't flake regardless of instrumentation overhead, while the two entries under test still expire via the short default TTL.

Verification

  • pnpm test:coverage — 57/57 files, 1298/1298 tests passing (previously 1 flaky failure)
  • pnpm test — 57/57 files, 1298/1298 tests passing
  • pnpm lint — 0 errors, 44 pre-existing warnings (unrelated)
  • pnpm build — clean

🤖 Filed by Fro Bot autohealing (schedule-95a0d398-29069840394) — category 5 quality gate fix.

…mentation

The 'should cleanup only expired entries' test used a 100ms default TTL
for all three cache entries, including the 'fresh' entry that should
survive cleanupExpired(). Under v8 coverage instrumentation overhead
(pnpm test:coverage), the extra time between adding the fresh entry and
calling cleanupExpired() could exceed the 100ms TTL, causing the fresh
entry to be incorrectly expired (removedEntries: 3 instead of 2).

Give the fresh entry a long custom TTL so it can't flake regardless of
instrumentation overhead, while the two entries under test still expire
via the short default TTL.
This was referenced Jul 10, 2026
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