You called startSpan. Who decides whether it leaves?

Break it

Four perturbations, and none of them is scripted — each one is the same run with one control moved.

1. Drag the sampling ratio down and tick RECORD_ONLY. The middle outlet lights up. Those spans are created, recorded and readable inside the process, and the exporter never sees one of them. Almost nobody knows that outlet exists.
2. Set maxQueueSize to 4 and let it run. The queue refuses. The drop is a fact in the model, not a silence — it leaves by its own outlet and it is counted.
3. Kill the process, then kill it again with ForceFlush. Same run, one parameter. Without the flush the queue dies with the process; with it, one control line descends to every registered processor and the batch leaves first. That is why spans vanish at the end of a short job.
4. Turn on trace_based, then drop sampling to zero. Logs stop arriving. The only thing joining those two facts is a single dashed line crossing from one provider into another.

Predict before you look

Answer first, then run it. Predicting and being wrong is what makes the answer stick; watching and recognising is not the same thing.

Instrument it

Two decisions from the file that actually runs in labs/providers/. The correct block is not written here — it is lifted out of that file, so it cannot drift from the code that compiles. The wrong ones are real: both of them ship to production regularly.

 
Span span = tracer.spanBuilder("GET /checkout").startSpan();
try (var escopo = span.makeCurrent()) {
  span.setAttribute("http.route", "/checkout");
} finally {
  span.end();
}

Resource recurso =
    Resource.getDefault().merge(
 
    );

SdkTracerProvider provider =
    SdkTracerProvider.builder()
        .setResource(recurso)
        .setSampler(
            Sampler.traceIdRatioBased(
                Double.parseDouble(variavel("OTEL_TRACES_SAMPLER_ARG", "1.0"))))
        .addSpanProcessor(
            BatchSpanProcessor.builder(
                    OtlpGrpcSpanExporter.builder()
                        .setEndpoint(
                            variavel("OTEL_EXPORTER_OTLP_ENDPOINT", "http://localhost:4317"))
                        .build())
                .setScheduleDelay(
                    Duration.ofMillis(Long.parseLong(variavel("OTEL_BSP_SCHEDULE_DELAY", "5000"))))
                .build())
        .build();

What people get wrong

Every row below is a belief worth naming, because the drawing above is arranged to take it apart. The right column is the spec, with the link.

What is deliberately not here

The channel out of the process is opaque, and it says so when you click it. HTTP/2 framing, length prefixes and stream ids are real, and they answer a different question than this lab asks — they are the gRPC over HTTP/2 annex and the Collector pipeline lab. What happens inside the Collector is not modelled here either: it is another program, it is drawn outside the process for that reason, and drawing it as an empty box would be worse than saying so.

Retry is missing on purpose too, and its absence is content: the spec says the default SDK must not implement retry, because the logic depends on the protocol. Modelling it here would be a lie about the SDK.

Check yourself

1. Two TracerProviders in one process, with different resources. What fails? Nothing. You get two resourceSpans with different service.name, no error anywhere, and a backend that quietly stops correlating them.
2. The queue is full and the metric store is at its cardinality limit. Do they lose data the same way? No. The queue refuses and the span is gone; the store collapses the excess into a single otel.metric.overflow row and the sum is preserved. Same problem — finite memory — two different lies.
3. Your SDK never came up. What is the first symptom? Silence. No exception, no warning, a no-op provider swallowing spans. It is the most common first-instrumentation failure, and the only way to teach it is to put a number on it.