When a ShardingTest/ReplSetTest fixture using the disaggregated-storage override fails partway through construction (e.g. a mongod node fails to start), the SLS resources it allocated are never released, because the owning test never reaches its teardown. A subsequent test in the same shell then fails with a misleading error instead of the real cause:

assert failed : Another replica set under the same name
(test_change_stream_sharding_fsm_fetch_and_resume-configRS) is already active

This masks the underlying failure and turns one real failure into a confusing cascade of two, sending investigators down the wrong path.

Root Cause. The disagg override tracks SLS resources in a module-level map (allocatedResourcesByReplSetName) and only frees them from stopSet()
(via _freeSLSResourcesFor()).

When fixture construction throws, no stopSet() runs, so the allocations leak. In the observed case the test body assigns the fixture only after construction completes:

let env;
afterEach(() => env?.teardown());
it(...) { env = setupFsmCluster(...); /* throws here */ }

Because setupFsmCluster() throws inside new ShardingTest(), the assignment to env never completes, so afterEach's env?.teardown() is a no-op and the partially-built cluster is never stopped. The leaked entries then collide with the next test, and _provisionSLSResourcesFor() asserts "already active".