BatchSpanProcessor export timeout configuration transition and span-drop reporting gap

Short answer: no OpenTelemetry SDK guarantees a countable, cross-language event when spans are dropped because an export deadline expires. Timeout-induced drops are handled inside the SDK/exporter boundary, and whether anything is surfaced — an error-handler callback, a metric, or only a debug log line — depends on the language and SDK version. If you need reliable accounting of export loss, you must add it yourself.

What is confirmed vs. what is likely

Confirmed, well-established behavior:

• The export timeout is a per-export deadline, set via OTEL_EXPORTER_OTLP_TIMEOUT (or an API-level timeout/deadline option). The BatchSpanProcessor passes a context carrying that deadline to the exporter.
• When the deadline elapses, the in-flight export is abandoned. The batch is not automatically re-queued for indefinite retry; those spans are effectively lost.
• forceFlush() and shutdown() honor context cancellation, so a bounded shutdown context can truncate the export window and cause the same kind of drop.

Likely, but version-sensitive (verify against your exact SDK release):

• Most SDKs log the failed export at debug/warn level rather than routing it to an application-visible error pipeline. Go's otel.Handle error handler receives some exporter errors, but timeout-driven batch abandonment is not uniformly funneled there across languages.
• Some SDKs emit self-telemetry metrics (names vary — e.g. processed/dropped span counters in Java's SDK metrics), but there is no spec-mandated metric name or cardinality for "dropped due to timeout," so dashboards built on one SDK's metric will not port.
• Default timeouts differ: Java has commonly defaulted to 30s for OTLP export, while Go, Python, and Node.js have their own defaults (often 10s) and have changed them across releases. Treat any specific number as unverified until checked in your SDK's changelog.

Answering the three sub-questions directly

1. Countable event? Not portably. There is no specification-level guarantee. Some SDKs expose internal dropped-span counters; others only log. Check your SDK's metric namespace before assuming a counter exists.
2. Error pipeline? Generally no. The drop is confined to internal SDK logging in most implementations. Application error handlers see exporter-returned errors in some languages, but a deadline-triggered batch discard is not consistently reported as one.
3. Shutdown reliability? This is the real operational risk. A Kubernetes terminationGracePeriodSeconds shorter than the export timeout, or a shutdown context with a tight deadline, means the final flush is cancelled mid-export and the remaining buffer is dropped — silently, from your application's point of view.

What to do about it

• Align three numbers explicitly: export timeout, flush/shutdown context deadline, and container grace period. The grace period must exceed the shutdown deadline, which must exceed the export timeout.
• Wrap the exporter (or use a custom SpanExporter decorator) to count failed exports and dropped batch sizes into your own metrics system. This is the only approach that works identically across languages.
• Enable SDK diagnostic/debug logging in staging and run a controlled SIGTERM test: generate a known number of spans, terminate, and compare exported count at the collector against produced count.

Verification checklist

# Controlled shutdown test (conceptual, any SDK)
OTEL_EXPORTER_OTLP_TIMEOUT=2000 \
OTEL_BSP_SCHEDULE_DELAY=500 \
./your-app &
PID=$!; sleep 5; kill -TERM $PID
# Compare: spans produced (app log) vs spans received (collector debug exporter)

If the gap matters for compliance or SLOs, do not rely on SDK-internal logging — instrument the loss yourself. One missing detail that would sharpen this answer: which SDK language and version you are running, since the exact metric names and error-handler behavior are version-specific and should be confirmed against that release's changelog.