Stop Auto Memory from retrying low-signal sessions indefinitely
Problem
Auto Memory only records a candidate session as processed when the extraction
agent successfully reads the transcript with read_file. If the agent sees a
session in the index and decides not to read it because it looks low-signal,
that session remains unprocessed and can be surfaced again in future runs.
Relevant code:
packages/core/src/services/memoryService.ts
The current flow tracks processed sessions through processedSessionKeys, which
is populated from successful read_file activity. Sessions that are surfaced to
the agent but intentionally skipped are recorded as candidates, but not as
processed.
Impact
- Low-signal sessions can repeatedly consume background extraction runs.
- The 30-minute throttle reduces frequency but does not solve repeated work.
- Backlog rotation helps, but repeated retries still make the service less predictable and more expensive over time.
Expected Behavior
Auto Memory should distinguish between:
- sessions successfully inspected via
read_file - sessions intentionally skipped as low-signal
- sessions that failed to read and may need retry
Low-signal skipped sessions should not keep resurfacing as new candidates on every extraction run.
Acceptance Criteria
- Candidate sessions can be recorded as skipped or attempted even if not read.
- Repeated low-signal sessions do not keep resurfacing every extraction interval.
- Failed reads remain distinguishable from intentional skips.
- Tests cover a candidate session that is surfaced but not read by the extraction agent.
Notes
This is primarily a background reliability and cost-control issue. The goal is not to force the extractor to read more sessions, but to persist a terminal or backoff state when it chooses not to inspect a candidate.
Source: google-gemini/gemini-cli