[cardmagic]

Summary

• test/caller-lifecycle.test.ts "recovers a pruned caller registration after runtime shutdown" failed once on PostgreSQL 14 in CI (run 39177376400), with expected +0 to be 1 at the manual retention.prune({ target: "processes" }).
• Cause, in the test: it kept the default retentionIntervalMilliseconds, so runtime.run started a scheduled retention pass at once (src/runtime.ts, MaintenanceScheduler). When that pass ran after the test backdated stopped_at_ms, it deleted the caller row first. The library behaved correctly.
• Fix, test only: this case calls setup({ retentionIntervalMilliseconds: 0 }), as wake-up, polling-loop, and background-pickup tests do.
• Test first: a spy on repository.pruneRetention holds any scheduled pass until the backdate is done. Before the fix it made the test fail with the CI message every time. After the fix no scheduled pass starts, and the spy stays as a guard.

Checks

• pnpm run check and pnpm test pass (704 passed, 32 skipped).
• The case passed 10 times in a row on SQLite.

[greptile-apps]

Confidence Score: 5/5

[Low impact] The PR appears safe to merge.

Summary

This test-only change keeps automatic retention from racing the caller recovery test.

• The caller recovery test controls when retention prunes its process row.

cardmagic explicitly keeps the spy as a regression guard; its extra coordination code is intentional.

_{Reviews (1) · Last reviewed commit: "test: keep scheduled retention out of th..." · Reviewed by Greptile}