Consider the simple test:

const coll = db.test;
coll.drop();

coll.createIndex(/* geospatial index spec */);
coll.insert(/* documents with geospatial data */);

coll.find(/* query using $near, $nearSphere or $geoNear */).toArray();

Let us try to execute this test in replica_sets_multi_stmt_txn_terminate_primary_jscore_passthrough suite. Network overrides will add w: "majority" to the createIndex command here. With these settings, the following timeline of execution is possible on MongoDB version 4.2:

First of all, we have 3-node replica set. node2 is Primary, all other nodes are Secondaries. Test issues createIndexes command, it arrives on Primary and command waits until the index is successfully built. To satisfy "majority" write concern, command is replicated to the node1. As soon as command is replicated, createIndexes command returns with success. It does not wait for node1 to finish the index build.

After the createIndexes command, the test suite issues a stepdown of Primary, which triggers a re-election. node1 is now selected as Primary. Note that the index build on node1 is still in progress.

After the new Primary was selected, test issues a find command with $near, $nearSphere or $geoNear operator. All these operators require a geospatial index to work. Since the geospatial index on the current Primary node1 is still building, it is not available for querying. Since there is no geospatial index available, query fails.

Note that starting from version 4.4 createIndexes with write concern "majority" actually waits for the index to finish building on the majority of nodes. So the affected versions are 4.2 and earlier.