OpenTelemetryExtension closes SDK prematurely with JUnit 5 @Nested test classes

[austince]

When using OpenTelemetryExtension with JUnit 5 @Nested test classes, the SDK is closed prematurely after the first nested class completes, causing subsequent nested classes to have non-functional metrics/spans/logs.

Root Cause

The afterAll() callback in OpenTelemetryExtension calls openTelemetry.close():

https://github.com/open-telemetry/opentelemetry-java/blob/main/sdk/testing/src/main/java/io/opentelemetry/sdk/testing/junit5/OpenTelemetryExtension.java#L196-L199

@Override
public void afterAll(ExtensionContext context) {
  GlobalOpenTelemetry.resetForTest();
  openTelemetry.close();
}

In JUnit 5, @AfterAll (and thus afterAll() extension callbacks) is called after each nested class completes, not just once at the end of the outer test class. This means:

1. First @Nested class runs → afterAll() → openTelemetry.close() called
2. Second @Nested class runs → SDK is already closed, metrics are not recorded
3. Subsequent @Nested classes → Same issue

Reproduction

@DisplayName("My Test")
public class MyTest {

  @RegisterExtension
  static final OpenTelemetryExtension otelTesting = OpenTelemetryExtension.create();

  @Nested
  @DisplayName("First nested class")
  class FirstNestedTests {
    @Test
    void test1() {
      // This test works - metrics are recorded
      var meter = otelTesting.getOpenTelemetry().getMeter("test");
      var counter = meter.counterBuilder("test.counter").build();
      counter.add(1);

      assertThat(otelTesting.getMetrics()).isNotEmpty(); // PASSES
    }
  }

  @Nested
  @DisplayName("Second nested class")
  class SecondNestedTests {
    @Test
    void test2() {
      // This test fails - SDK was closed after FirstNestedTests
      var meter = otelTesting.getOpenTelemetry().getMeter("test");
      var counter = meter.counterBuilder("test.counter").build();
      counter.add(1);

      assertThat(otelTesting.getMetrics()).isNotEmpty(); // FAILS - metrics are empty
    }
  }
}

Workaround

Currently the only workaround is to use @TestClassOrder with @Order annotations to ensure test classes that depend on metrics run first:

@TestClassOrder(ClassOrderer.OrderAnnotation.class)
public class MyTest {

  @Nested
  @Order(1)  // Run first before SDK is closed
  class MetricsTests { ... }

  @Nested
  @Order(2)
  class OtherTests { ... }
}

This is pretty clunky though. It might also work to recreate the extension in each nested test, but that kind of defeats the purpose of nesting.

Environment

• OpenTelemetry SDK version: 1.56.0
• JUnit 5 version: 5.x / 6.x
• Java version: 11+

[jkwatson]

Is there a more appropriate hook to be using to close the SDK, and would you be willing to submit a PR with the change?

[austince]

I'm not sure if there is a more appropriate hook, but it looks like the Otel instance that is built is all in memory -- is closing (in addition to resetting) necessary / what resources would be leaked?

opentelemetry-java/sdk/testing/src/main/java/io/opentelemetry/sdk/testing/junit5/OpenTelemetryExtension.java

Lines 70 to 99 in 40dbfa4

	InMemorySpanExporter spanExporter = InMemorySpanExporter.create();
	SdkTracerProvider tracerProvider =
	SdkTracerProvider.builder()
	.addSpanProcessor(SimpleSpanProcessor.create(spanExporter))
	.build();
	InMemoryMetricReader metricReader = InMemoryMetricReader.create();
	SdkMeterProvider meterProvider =
	SdkMeterProvider.builder().registerMetricReader(metricReader).build();
	InMemoryLogRecordExporter logRecordExporter = InMemoryLogRecordExporter.create();
	SdkLoggerProvider loggerProvider =
	SdkLoggerProvider.builder()
	.addLogRecordProcessor(SimpleLogRecordProcessor.create(logRecordExporter))
	.build();
	OpenTelemetrySdk openTelemetry =
	OpenTelemetrySdk.builder()
	.setPropagators(
	ContextPropagators.create(
	TextMapPropagator.composite(
	W3CTraceContextPropagator.getInstance(),
	W3CBaggagePropagator.getInstance())))
	.setTracerProvider(tracerProvider)
	.setMeterProvider(meterProvider)
	.setLoggerProvider(loggerProvider)
	.build();

[jkwatson]

I think we definitely need a way to un-set the global that is set at the beginning of the tests, so we have to figure out the right way to do that. Other than that, there's little that probably matters at that phase of things.