The ProtocolHelper#createSpecialException does not apply top level error labels to the write concern error.

This can wrongly lead to errors being deemed not retryable. In particular, it means a response to a write operation like:

{
    "ok": 1.0, 
    "errorLabels": ["RetryableWriteError"],   
    "writeConcernError": {
         "code": 11602, 
         "codeName": "InterruptedDueToReplStateChange", 
         "errmsg": "operation was interrupted",
    },
    "n": 1, 
    "nModified": 1, 
    ... 
}

will not be considered by the driver to be retryable.

The retryable writes spec states here that:

The driver MUST treat all errors with the RetryableWriteError label as retryable. This error label can be found in the top-level "errorLabels" field of the error. In a server error response with a writeConcernError field the top level document or the writeConcernError document may contain the RetryableWriteError error label.

So it seems the driver is in violation of that mandate, and it seems that there are no spec tests enforcing it or the driver has implemented the spec tests incorrectly so that they pass when they should not.