clear

Drop every record this exporter holds and delete the segments that held them — a supported reset the same live instance keeps exporting into (#2208).

The forgetting goes through Rga.dropWindow, not Rga.empty, and the difference is the whole design. A reset to empty re-mints RgaIds this replica has already used — maxSeqByReplica and the Lamport clock both restart — so a later merge with a peer holding the pre-clear ops resolves two different records onto one id by map-put order. A window pass instead raises the compaction floor, which carries the seq high-water forward and suppresses the dropped dots, so a peer holding the raw Inserts cannot push the records back either: Rga.piece merges the floor and re-purges beneath it.

The store settles to two small keys, not zero. The index and one active segment remain, the latter carrying the floor. That floor is what buys the paragraph above; deleting it would leave a literally empty store and an open resurrection hole. The sealed segments — which is where the bytes are — are deleted through the ordinary retirement ledger, so a refused delete is retried at the next start rather than leaked.

Reclamation is total only on the export path. A segment carrying an RgaOp.Compact is never retired and a merge-adopted segment is pinned entire, so a gossip-fed replica keeps residue after a clear. A replica fed only by export mints only its own dots, which fold into the floor, so every sealed segment becomes retirable.

Not a CRDT delete: this replica forgets, and so does any peer that merges from it afterwards, but the clear does not travel to a peer that never does.

And it does not travel to an AppliedOpSink either. Nothing is published here and no sink is asked to forget anything — a consumer that kept the records is supposed to still have them once this returns. A clear that reached through to an archive would make the archive a mirror of this buffer, which is the one thing an archive must not be: its whole value is outliving this replica's forgetting.

Never throws, on the same terms as export. A failed durable write returns ExportResult.Failure and moves ExporterHealth.failed — the store really did reject a write — while a successful clear never moves ExporterHealth.accepted, which keeps meaning "records durably taken". Retrying a failed clear re-converges: raising the floor is idempotent and a repeat delete is a no-op.

On failure, snapshot already reads empty while the store still holds the records. A turn builds its actions from already-mutated state — that is how all three write paths here work — so the drop is not undone. A caller that uses the record count as a baseline must treat any non-ExportResult.Success as count unknown rather than as zero. On success the count reads zero synchronously, because the drop precedes the write.