Bug Report: Recovery copies accumulate without throttling

[guge2477756717-wq]

Summary

Reasonix Desktop keeps generating "哈喽・副本" (recovery copy) sessions at a rate of roughly one every 20–60 seconds. Dozens accumulate within hours, filling the sidebar session list and eventually causing Hermes context-injection token-limit errors.

Environment

• Version: v1.24.1 (D:\reasonix\current.json → activeVersion: "v1.24.1"; Reasonix.exe FileVersion 1.24.1)
• OS: Windows amd64
• Client: Reasonix Desktop (reasonix-desktop.exe)

Symptoms

1. The sidebar shows a large number of duplicate sessions named "哈喽・副本".
2. These copies cannot be deleted from the UI — deleting one causes it to be regenerated immediately.
3. Each copy fully inherits the project context, so the accumulated copies keep growing token usage and trigger Hermes context-injection limit errors.

Root-cause analysis

In the session catalog database C:\Users\hande\AppData\Local\reasonix\session-catalog\v2.sqlite, table catalog_sessions:

• 40 total rows, of which 39 have recovered = 1
• recovery_reason breakdown:
  • snapshot conflict × 28
  • rewrite conflict × 11
• Copies are created ~20–60 seconds apart (see timestamp sequence below)

Sample conflicts.jsonl entry:

{"at":"2026-08-14T22:01:12.6680031+08:00","branch_id":"...-recovery-7b6ece3165b863fa-2a12b6d0e28a",
 "mode":"rewrite","outcome":"recovery_depth_cap_isolated","kind":"diverged",
 "disk_messages":221,"snapshot_messages":229,"base_revision":1,"disk_revision":1,
 "recovery_branch_id":"...-recovery-c4717ff6fce5e459-2a12b6d0e28a"}

Key observation: outcome = "recovery_depth_cap_isolated" and kind = "diverged", with disk_messages (221) != snapshot_messages (229). Every snapshot/rewrite pass that detects the session file has diverged creates a new recovery copy, with no throttling or merging for the same source session.

Concurrent processes (likely trigger)

At the time of the issue, 5 Hermes.exe + 1 reasonix-desktop.exe processes were running simultaneously, all writing to the same session branch and continuously triggering snapshot/rewrite conflicts.

Timestamp sequence (partial, ~20–60 s apart)

1786713761465  snapshot conflict
1786713821462  snapshot conflict
1786713848805  rewrite conflict
1786714059588  snapshot conflict
1786714089561  snapshot conflict
1786714119563  snapshot conflict
1786714179561  snapshot conflict
1786714209564  snapshot conflict
1786714239570  snapshot conflict
1786714329564  snapshot conflict
1786714359571  snapshot conflict
1786714449568  snapshot conflict
1786714479578  snapshot conflict
1786714539586  snapshot conflict
1786714599589  rewrite conflict
...（continues up to 1786716141551）

Expected fixes

1. Throttle/merge recovery copies for the same source session: repeated conflicts within a short window (e.g. 1 hour) should be merged into the existing recovery copy instead of creating a new one each time.
2. Stop generating further copies once recovery_depth_cap_isolated is reached: the current behavior keeps creating copies even after this outcome, suggesting the depth cap is not being enforced.
3. Provide a batch-cleanup entry point: the RecoveryCopy flag already exists (the v1.24.1 changelog mentions "recovery copies are now correctly classified"), but the UI still cannot delete them — a "clean up recovery copies" action is needed.
4. Optionally: expose the recovery-copy retention window / throttle interval as a [checkpoints] config option (the CHECKPOINTS.md "Open questions" section already asks whether the default retention window should be exposed in [checkpoints] config).

Notes

• While the client is running, externally deleting copy files or editing the database has no effect (WAL mode plus the client's save mechanism overwrites/rebuilds them), so this cannot be fixed from inside a chat.
• Related changelog entries: v1.24.1 "Recovery copies correctly classified in the session catalog" and "Recovery copy duplicate counting and cleanup races"; v1.19.6 "CLI recovery session grouping" — but the throttling/merging issue remains unresolved.

---

Generated by Reasonix diagnostics. Submit to https://github.com/esengine/DeepSeek-Reasonix/discussions or Issues (tag the v2 code line).