Spans dir: rotation / TTL so ~/.local/share/repo-recall/spans/ doesn't grow without bound #55

New issue

Closed

opened 2026-05-23 20:55:28 +00:00 by coilysiren · 1 comment

coilysiren commented

2026-05-23 20:55:28 +00:00

Owner

Originally filed by @coilysiren on 2026-05-09T02:09:56Z - https://github.com/coilysiren/repo-recall/issues/68

Cleanup debt from the LUCA tracer (luca#27).

Problem

The spans ingest dir (~/.local/share/repo-recall/spans/ or REPO_RECALL_SPANS_DIR) is append-only today. Every subagent run drops one file. There is no rotation, no TTL, no GC.

repo-recall's cache wipes on every restart and re-ingests on every refresh, which means the cost of accumulated spans hits both directory walks and the wipe-rebuild cycle. With the SubagentStop hook live globally (coilysiren/coilyco-ai's promote-to-global issue), file count grows roughly N-subagents per session, which gets out of hand fast.

Candidate fixes

TTL on disk: a small GC pass at refresh time that deletes files older than N days. Symmetric with the existing 30d cutoff repo-recall already uses for commits/churn.
repo-recall spans gc verb (HTTP or CLI) that operators or cron can invoke.
Capped-count rotation: keep the most-recent K spans, drop older ones. Simpler than TTL but lossier.
Producer responsibility: have o2r and the hook script delete after successful ingest. Couples producer to consumer; rejected unless there's a strong reason.

Default recommendation: TTL during refresh, with a config var REPO_RECALL_SPANS_TTL_DAYS defaulting to 30.

Done when

~/.local/share/repo-recall/spans/ does not grow indefinitely.
The chosen mechanism is documented in AGENTS.md alongside the existing data-source guidance.
A test exercises the GC path (drops an old-mtime span file and asserts it's removed at refresh).

_Originally filed by @coilysiren on 2026-05-09T02:09:56Z - [https://github.com/coilysiren/repo-recall/issues/68](https://github.com/coilysiren/repo-recall/issues/68)_ Cleanup debt from the LUCA tracer (luca#27). ## Problem The spans ingest dir (`~/.local/share/repo-recall/spans/` or `REPO_RECALL_SPANS_DIR`) is append-only today. Every subagent run drops one file. There is no rotation, no TTL, no GC. repo-recall's cache wipes on every restart and re-ingests on every refresh, which means the cost of accumulated spans hits both directory walks and the wipe-rebuild cycle. With the SubagentStop hook live globally (coilysiren/coilyco-ai's promote-to-global issue), file count grows roughly N-subagents per session, which gets out of hand fast. ## Candidate fixes - **TTL on disk**: a small GC pass at refresh time that deletes files older than N days. Symmetric with the existing 30d cutoff repo-recall already uses for commits/churn. - **`repo-recall spans gc`** verb (HTTP or CLI) that operators or cron can invoke. - **Capped-count rotation**: keep the most-recent K spans, drop older ones. Simpler than TTL but lossier. - **Producer responsibility**: have o2r and the hook script delete after successful ingest. Couples producer to consumer; rejected unless there's a strong reason. Default recommendation: TTL during refresh, with a config var `REPO_RECALL_SPANS_TTL_DAYS` defaulting to 30. ## Done when - `~/.local/share/repo-recall/spans/` does not grow indefinitely. - The chosen mechanism is documented in AGENTS.md alongside the existing data-source guidance. - A test exercises the GC path (drops an old-mtime span file and asserts it's removed at refresh).

coilysiren added the

label

2026-05-31 01:55:01 +00:00

coilysiren added

and removed

labels

2026-06-04 08:16:38 +00:00

coilysiren commented

2026-06-17 08:24:28 +00:00

Author

Owner

Backlog burndown 2026-06-17: closing low-priority (P3/P4) to bring the open count to a manageable level. Nothing lost — reopen if this resurfaces. Batch tag: burndown-2026-06.

Backlog burndown 2026-06-17: closing low-priority (P3/P4) to bring the open count to a manageable level. Nothing lost — reopen if this resurfaces. Batch tag: `burndown-2026-06`.

coilysiren

2026-06-17 08:24:28 +00:00