telemetry

const (
	LargeSpanQueueSize       = 16384 // 16Ki — 8x the SDK default; bounds retained snapshots per hop
	LargeSpanExportBatchSize = 2048  // drains a full queue in 8 batches; bounds per-batch references
)

Enlarged, BOUNDED BatchSpanProcessor sizes for the span hops that carry a trace toward Dagger Cloud. The OTel BSP queue is non-blocking and silently DROPS spans on overflow; the SDK default of 2048 slots is too small for a burst like a cold engine build (~15k spans, live-double-emitted into ~30k records), which is why these hops use a larger queue at all.

The queue must stay MODEST as well as bounded, because its worst case is paid per PROCESSOR, and processors multiply: every client gets one such processor for its own DB plus one per ancestor client, each with an eagerly allocated ring (16 bytes/slot) that can fill with full span snapshots whenever the store exporter falls behind. A heavily grouped CI session can hold dozens of clients, so per-processor worst case × processor count is the engine's telemetry memory ceiling. At 16Ki slots the per-processor ceiling is ~16 MiB of retained snapshots (at ~1 KiB each) plus a 256 KiB ring — 16x below the previous 256Ki sizing, which put a loaded session's aggregate worst case far past the physical memory of a typical CI runner — while still giving 8x the SDK default's burst headroom.

Kept BOUNDED — never BlockOnQueueFull — so telemetry can NEVER stall the build. If a burst still overflows, spans are dropped rather than retained: the wcprof completeness checksum (received < declared, see engine/server/wcprofcount.go) catches the loss loudly and the offline analyzer refuses the trace instead of silently ranking on partial data.

const (
	LogExportInterval     = 250 * time.Millisecond
	LogExportMaxBatchSize = 128
)

Log-record batch settings for the per-client DB log routes (engine/server).

The SDK BatchProcessor's poll loop clones its entire batchSize-long []Record buffer on EVERY export tick while the exporter is ready — even when zero records were dequeued (sdk/log batch.go: TryDequeue's write callback does buf = slices.Clone(buf), and EnqueueExport returns true for an empty slice). A Record is a large struct (~0.5 KiB inline), so the resulting allocation churn is processors × ticks/sec × batchSize × sizeof(Record), INDEPENDENT of actual log volume. The engine registers one processor per client per ancestor route, so a grouped session easily holds 100+ of them; at the previous 100ms interval and default 512 batch this produced tens of GB of allocation churn per run (measured: 22–37 GB of slices.Clone[[]sdklog.Record] in a grouped python-sdk check run).

Interval and batch size each scale that churn linearly. Crucially, OnEmit self-flushes as soon as a full batch accumulates (pollTrigger), so a longer interval delays only SPARSE log records — bursts still export immediately. 250ms/128 cuts the volume-independent churn ~10x while keeping trickle latency well below human-noticeable for log output.

const HeartbeatInterval = 30 * time.Second