Swap: retry a journal's recovery checkpoint while idle

After a lost record the journal drops position-based records until a
full checkpoint. That checkpoint was only requested from later edits,
rate-limited to once a second; when the writer handled the failing
record before its edit asked for a checkpoint, the checkpoint failed as
well and consumed the slot, so edits made within the next second were
not recovered and, if the user stopped typing, the journal stayed behind
indefinitely. SwapManager::RetryGapCheckpoints(), called once per frame
from Editor::ProcessPendingOpens, requests it once the interval has
passed. This also made SwapReplay_LostRecord_ResyncsWithCheckpoint flaky
under load; the test now exercises the retry.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015rcVQiiWyTzoNrsvLSaAfB
This commit is contained in:
Claude
2026-09-24 09:16:04 -07:00
committed by Kyle Isom
parent b1b0b3de57
commit 1e312fcd0b
5 changed files with 46 additions and 0 deletions
+6
View File
@@ -424,6 +424,12 @@ before the fix (unless noted).
the skip now applies only to search-as-you-type (at 2,000 bytes, where
the worst case is well under a second), says so in the status line,
and moving to the next/previous match searches every line.
- After a lost journal record, the recovery checkpoint was requested
only by later edits, at most once a second; if the first attempt
failed and the user then stopped typing, the journal stayed behind
indefinitely. The editor loop now retries it each second while idle
(this was also why SwapReplay_LostRecord_ResyncsWithCheckpoint was
flaky under load).
**Known limitations (not fixed)**
- Catastrophic regex backtracking (e.g. `(a*)*b`) can still take very