clear
Drop every span this exporter holds and persist the emptied set (#2208).
Removal, not ORSet.empty: an ORSet removal retains causal.context, so the retired dots stay witnessed and a peer re-merging the pre-clear adds is dominated rather than resurrecting them. An emptied-by-reset set would re-mint dots this replica has already used, and a peer whose context already holds one would treat the new span as seen-and-removed — swallowing it silently.
The key is rewritten rather than deleted, because the retained context is what the paragraph above rests on and it lives in those bytes.
One ORSet.removeAll, not a per-element fold. Absorbing a patch is a causal join over the whole set, so removing one element at a time pays a join per element: measured here at DEFAULT_MAX_SPANS that fold was quadratic and cost seconds, which is why the bulk form exists (#2245). The two are otherwise indistinguishable — same elements gone, same dots retired, same retained context, same bytes.
A configured WarpCausalClock's frontier is emptied here too, and its seq left alone. The frontier would otherwise name dots of spans this call just removed, so the next auto-stamped span would carry predecessors that can never resolve — links pointing at deliberately forgotten spans, which is noise rather than causality.
Shares ioMutex with export and merge so a concurrent export cannot land a stale encoded snapshot after the clear.
Never throws, on the same terms as export: a refused durable write is reported as ExportResult.Failure carrying the store's cause, never propagated. Retrying a failed clear re-converges — ORSet.removeAll over an already-emptied set is the lattice identity, emptying an already-empty frontier is too, and neither write is gated on the drop having moved anything, so the retry writes the same bytes the first attempt would have. Gating them on that is the obvious optimisation and it silently breaks the retry: a failed clear has already emptied memory, so a gated retry would find nothing to drop, write nothing, and report ExportResult.Success over a store that still holds every span.
On failure, snapshot already reads empty while the store still holds every span, and a configured clock's WarpCausalClock.frontier likewise reads empty while the persisted one still names the pre-clear dots. Both mutations precede the writes and — unlike export, which rolls a freshly-minted stamp back out — neither is undone. A caller that uses the span 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.