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

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.