gemini-cli - 💡(How to fix) Fix Stop Auto Memory from retrying low-signal sessions indefinitely [1 comments, 2 participants]

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.