Right now our logic to process batch command responses for bulkWrite on mongos assumes that, if we have a response, it strictly matches the form of BulkWriteCommandReply.

However, it is possible that we get back top-level error responses e.g. if a transient transaction error occurs, which currently can lead to parsing errors here. For example:

{"errorLabels":["TransientTransactionError"],"ok":0,"errmsg":"sharding status of collection test.coll is not currently known and needs to be recovered","code":13388,"codeName":"StaleConfig","ns":"test.coll","vReceived":{"e":{"$oid":"000000000000000000000000"},"t":{"$timestamp":{"t":0,"i":0}},"v":{"$timestamp":{"t":0,"i":0}}},"shardId":"shard-rs0","$clusterTime":{"clusterTime":{"$timestamp":{"t":1692221464,"i":25}},"signature":{"hash":{"$binary":{"base64":"AAAAAAAAAAAAAAAAAAAAAAAAAAA=","subType":"0"}},"keyId":0}},"$configTime":{"$timestamp":{"t":1692221464,"i":19}},"$topologyTime":{"$timestamp":{"t":1692221457,"i":4}},"operationTime":{"$timestamp":{"t":1692221464,"i":25}}}

Additionally, the logic for batch insert/update/delete has some special casing for errors with the TransientTransactionError label, which we don't appear to have yet for bulkWrite.

These issues can be observed by running bulk_write_update_cursor.js or bulk_write_delete_cursor.js in the sharded_multi_stmt_txn_jscore_passthrough suite and will also appear less consistently in other bulkwrite core tests and txn passthroughs where we may see StaleConfig errors.

It would be good to add some targeted tests around handling of these reply types along with fixing this.