BufferPolicy

Controls what happens when the in-memory CRDT buffer reaches maxSpans.

Honest limits

An offline-forever device cannot buffer forever. The degradation is intentionally asymmetric and accounted for — never silent:

• Metrics compress losslessly (a counter is O(1) regardless of how many increments happen offline). Buffer caps only apply to spans and logs.

• When a cap is hit, the BufferPolicy decides what gives way, and the loss is always visible. How it is made visible differs by exporter, because the two run at very different rates:

• WarpSpanExporter logs each drop, with the victim's SpanRecord.traceId and SpanRecord.spanId, so an operator can correlate against their backend's orphan-span index.

• WarpLogRecordExporter counts each drop exactly, on ExporterHealth.dropped / ExporterHealth.refused, and emits one rate-limited summary line rather than one line per record. At DEFAULT_MAX_LOG_RECORDS its buffer is full permanently, so every exported record evicts one — a per-record line there narrates a ring buffer doing exactly what it is configured to do, on the export hot path (#2218). Per-record correlation was given up deliberately; the running total was not.

The DROP_OLDEST strategy is usually right: oldest spans are already "done" and are the least likely to complete a trace being actively sampled right now.