The change log grows without a ceiling, and everything looks healthy while it does

Type

Operability gap — a capability exists and nothing exposes it

Found while

SAPE-26

Triage

Defer

Status

Open

Severity

Low today, certain later — this is a week-three problem, not a day-one one

Description

store.Retain exists and works. No server option reaches it. So an operator running sapedbd has no way to say how much history to keep, and the change log grows for as long as the database is written to.

There is a second, quieter consequence. The too_far_behind refusal — a follower asking for an entry that has been trimmed away — cannot happen on sapedbd today at all. Only an embedder calling Retain directly can produce it. A refusal path that no shipped configuration can reach is a refusal path nobody has operated.

Evidence

• store.Retain is defined and covered by its own tests.
• No flag, environment variable or config field in cmd/sapedbd calls it — measured by grepping the server's option handling for the symbol.
• SAPE-26's test for a trimmed log had to call Retain from the test itself to construct the condition, which is what surfaced this.

Triage

Does it lose data, break a promise on a public surface, or stop somebody installing and running? No — nothing is lost, nothing public is contradicted, and a first-day install runs fine. So it defers, by the same rule everything else defers by.

Said plainly anyway, because the deferral has a shape: this is what bites the first operator in their third week, on a disk that filled while every health signal stayed green. Adding the option later is purely additive and breaks nobody, which is the whole reason it is safe to wait.