This is a test-only bug - jstests/core_sharding/query/trivially_empty_queries.js hardcodes the moveRange bounds as [{_id:0}, {_id:5}). In this suite, the balancer's random-migration failpoint can split that chunk at an arbitrary point. Once that happens, the hardcoded bounds no longer correspond to a single chunk, and moveRange fails with non-retryable error Location11089203. The test uses assert.soonRetryOnAcceptableErrors, but 11089203 is not in its acceptable-error list, so the test exits instead of retrying.

assert: command failed: { "ok" : 0, "errmsg" : "Range with bounds [{ _id: 0.0 }, { _id: 5.0 }) is not contained within a single chunk.", "code" : 11089203, "codeName" : "Location11089203" } 

trivially_empty_queries.js is the end-to-end guard for SERVER-84547, responsible for ensuring queries the optimizer can prove are empty must still target exactly one shard, not all shards and not zero shards. But every observed failure has come from the setup intended only to place the collection on multiple shards.

The test is also incompatible with add/remove-shard transition suites because it assumes a stable shard topology. It resolves destination shard ids up front and continues to target them throughout the run, while this suite can drain and re-add shards under new ids. In that environment, failures in moveRange setup are expected and are orthogonal aim of the test.

Excluding it from this one suite will not create a coverage gap. The invariant is still covered by dedicated C++ unit tests, and the jstest continues to run in the other sharding suites, including sharding_jscore_passthrough_with_balancer, which preserves coverage against concurrent migrations and routing-table churn.