The test attempts to construct a replica-set connection string of the form "rsName/host" to the shard member that responded to the currentOp, using the shard name from the "shard" field of the currentOp output as the rs name and the "host" field from the currentOp output as the host. It could simply instead use just the host name, or get the replica set name otherwise.

The shard field in this output corresponds to the Shard-Name. In most cases, this works fine, because the way ShardingTest configures the cluster means that the shard-name is replica set name. But with config-shards, the shard-name is always to "config", which is not the replica-set name. See for example this output of sh.status from a two-shard cluster where one of the shards is a config shard:
mongos> sh.status()
— Sharding Status —
sharding version:

{ "_id" : 1, "clusterId" : ObjectId("664cf8071b3e88c64d95d6b9") }

shards:

{ "_id" : "__unknown_name__-rs1", "host" : "__unknown_name__-rs1/ip-10-122-4-26:20001", "state" : 1, "topologyTime" : Timestamp(1716320266, 13), "replSetConfigVersion" : NumberLong(-1) } { "_id" : "config", "host" : "__unknown_name__-rs0/ip-10-122-4-26:20000", "state" : 1, "topologyTime" : Timestamp(1716320266, 10), "replSetConfigVersion" : NumberLong(-1) }