This test sets up a change stream pipeline to run on both shards, establishes a find cursor on both shards, tears down one shard to induce a network exception on the next getMore, and verifies that the change stream error returned to the client has the expected ResumableChangeStreamError label while the find error does not. The reason the test is failing is because it does not explicitly set which shard is the primary shard for the test database at the outset. If the "wrong" shard is chosen by the system, then the test will not encounter a network error when issuing the getMore, since it will be sent only to the shard that still exists.

The find cursor is run with a batchSize of 2 in order to ensure that the cursor does not consume all results and close after the first batch. This causes 2 results to be retrieved from each shard and cached on mongoS. Because the results are sorted, the first 2 results returned by the mongoS are both drawn from the shard with the {MinKey, {_id: 0}} chunk - that is, the primary shard. We then tear down one of the shards and issue a getMore on the cursor. If the shard that has been torn down was the shard from which the initial two results were drawn, then the mongoS will attempt to issue a getMore to that shard to refill its empty cache, only to find the shard uncontactable. If, however, we have just torn down the shard whose results are still cached on mongoS, then mongoS will not issue a getMore to the downed shard; instead, it will issue a getMore to the shard that still exists, the getMore will succeed, we will not throw the expected exception, and the test will fail as a result.

We should explicitly set the primary shard on startup, and make sure that this is the shard that we tear down later in the test.