driver-core/src/test/resources/junit-platform.properties

• 🟡 [important] L1: Autodetection leaks to downstream modules via testArtifacts.
  Verified: buildSrc/.../test-artifacts.gradle.kts builds the test JAR with from(sourceSets.test.get().output), which bundles processed test resources (including this file and the META-INF/services
  registration) alongside compiled test classes. driver-sync/build.gradle.kts:38 (and other modules) declare testImplementation(project(path = ":driver-core", configuration = "testArtifacts")). Net effect:
  junit.jupiter.extensions.autodetection.enabled=true and the ThreadDumpOnFailureExtension get activated for every consuming module's test run, not just driver-core. Two risks: (a) unintended global
  activation the author may not have planned for; (b) if any consuming module ships its own junit-platform.properties, JUnit Platform's classpath resolution of a single junit-platform.properties becomes
  order-dependent/non-deterministic. If global activation is actually desired, that's defensible — but it should be a deliberate, documented decision. Otherwise scope it via the Gradle Test task system
  property (systemProperty("junit.jupiter.extensions.autodetection.enabled", true)) in the relevant module(s).

driver-core/src/test/unit/com/mongodb/internal/diagnostics/ThreadDumpOnFailureExtension.java

• 🟡 [important] L44-54: ThreadInfo.toString() truncates each stack to 8 frames.
  The JDK's ThreadInfo.toString() is hardcoded to emit at most MAX_FRAMES = 8 stack frames per thread, then prints .... Given the stated motivation (diagnosing a deadlock), 8 frames is often too shallow
  to see where threads are actually blocked. For a complete dump, iterate frames yourself, e.g. build the header from ThreadInfo and append the full info.getStackTrace(). The lock/monitor info you correctly
  enabled (below) also only renders for frames within that 8-frame window when using toString().

• 🟢 [nit] L46-49: Captures dumps only for tests that fail, not tests that hang.
  TestWatcher.testFailed fires only when a test produces a failure. A true deadlock that hangs until the Gradle/JVM test timeout kills the process never reaches testFailed, so no dump is produced for that
  case. Worth being aware of relative to the deadlock-diagnosis goal; a JVM-level/@Timeout-driven approach would be needed to cover hangs. Not blocking for the failure-path use case.

• 🟢 [nit] L20-31: Import grouping and double blank lines.
  Imports are grouped java.* first then com.mongodb.*/org.*, with doubled blank lines (L21-22, L29-30). I checked config/checkstyle/checkstyle.xml — only RedundantImport/UnusedImports are enforced,
  so this will not fail CI. Purely cosmetic; tidy up the consecutive blank lines if touching the file.

• 🟢 [nit] L48-52: No delimiter between concatenated thread entries.
  sb.append(info) relies on each ThreadInfo.toString() trailing newline. A clear header/footer (e.g. ===== THREAD DUMP (test: X) =====) would make dumps far easier to locate and bound in large Evergreen
  logs.

• 🎉 [praise] L46-49: Good defensive dumpAllThreads call — passing isObjectMonitorUsageSupported() / isSynchronizerUsageSupported() captures lock-ownership info, which is exactly what's useful for
  deadlock analysis. Nicely done, and the SecurityException fallback keeps the extension from masking the real test failure.

Prior Review Comments

• 🎉 [praise] Extension.java:50 — Wrap thread-dump generation in try/catch. Addressed — current code catches SecurityException and returns a fallback message.
• 🎉 [praise] Extension.java:36 — Logger naming should use a short suffix. Addressed — now Loggers.getLogger(ThreadDumpOnFailureExtension.class.getSimpleName()). Confirmed against
  Loggers.getLogger (prepends org.mongodb.driver.), so getSimpleName() is the right convention.
• 💡 [suggestion] Extension.java:42 — Log the cause too. Disputed by the author ("the cause will already be provided on assertion fail"). Reasonable: JUnit already reports the failure cause
  independently, so this is largely redundant. Minor counterpoint — logging the cause keeps it adjacent to the dump in the same log line for correlation — but not worth blocking.
• 🟡 [important] junit-platform.properties:1 — testArtifacts JAR propagates this setting to other modules. Unaddressed. Merged with the L1 finding above; I independently verified the build wiring
  confirms the concern.
• 🟢 [nit] Extension.java:43 — Full dump on every failed test can flood logs on cascading failures. Unaddressed. Valid for failure storms; consider throttling (once per JVM via AtomicBoolean)
  and/or the delimiter suggested above. Low priority for a diagnostic util.
• 🟢 [nit] Extension.java:30 — Import order inconsistent with repo convention. Unaddressed. Cosmetic only (not Checkstyle-enforced) — see nit above.

Decision:

1. junit-platform.properties propagation — confirm whether enabling autodetection + the extension across all :driver-core testArtifacts consumers (driver-sync, etc.) is intended. If yes, add a
   comment in the properties file documenting it. If no, scope it via a per-module Gradle Test system property instead.
2. 8-frame truncation — replace ThreadInfo.toString() with explicit iteration over info.getStackTrace() so deep deadlock stacks aren't cut off at 8 frames.

Placing junit-platform.properties under driver-core/src/test/resources means it is packaged into driver-core:testArtifacts, which is consumed by driver-sync, driver-reactive-streams, driver-scala, anddriver-legacy. Those modules will unintentionally inherit JUnit extension autodetection and load ThreadDumpOnFailureExtension for all their test failures.

That changes behavior outside driver-core and could produce very large logs during broad/cascading failures. Suggested fix: avoid classpath-wide autodetection from shared test artifacts, or configure it per module via Gradle/system property if global behavior is intended.