BatchSpanProcessor / BatchLogRecordProcessor: add opt-in blocking mode when queue is full

[cijothomas]

Problem

Both BatchSpanProcessor (sdk.md#batching-processor) and BatchLogRecordProcessor (logs/sdk.md#batching-processor) drop items when maxQueueSize is reached. This is intentional — telemetry must not affect application behavior by default.

Item loss is observable via the SDK self-observability metrics defined in semantic conventions (experimental status), though only a subset of SDKs currently implement them.

However, there are workloads where drop is not the right trade-off:

• Batch / offline jobs — a data pipeline that runs and exits has no latency-sensitive path. Dropping spans because the exporter lagged is incorrect behavior; accepting backpressure is acceptable.
• Compliance / audit workloads — some environments require complete telemetry records and cannot tolerate loss.

Proposal

Add an opt-in onQueueFull parameter to both processors:

• DROP — current behavior, remains the default. No breaking change.
• BLOCK — the calling thread blocks until queue space is available, or until blockOnQueueFullTimeoutMillis elapses, after which the item is dropped.

A dedicated blockOnQueueFullTimeoutMillis parameter (only meaningful when onQueueFull = BLOCK) would be introduced alongside.

Related

• Batching Configuration Standardization project — active cross-SIG effort to unify batching config across SDKs and Collector; this proposal is in scope for that work.

[svrnm]

@cijothomas have you presented this during a spec meeting already? I think it would be good to share it with a broader audience. Thanks.

[cijothomas]

@cijothomas have you presented this during a spec meeting already? I think it would be good to share it with a broader audience. Thanks.

No. Due to timezone constraints, I won't be able to join Spec meetings for another 2 more weeks :(

I've requested @braydonk to help triage and see if this should be worked on as part of the Batching configuration project.