ArgumentError w/rc=RC0x21 raised for all durability errors - why are other err codes not used?

I’m testing out the persist_to= and replicate_to= param functionality in the mutator methods (insert(), upsert(), etc) in the PySDK, and no matter what values I pass, I get the same exception for a durability violation: an ArgumentError exception object with rc=RC0x21, e.g.:

<RC=0x21[Durability constraints requires more nodes/replicas than the cluster configuration allows. Durability constraints will never be satisfied], Durability requirements will never be satisfied, C Source=(src/oputil.c,545)>

Now, this certainly describes my situation. But I am wondering why this return code is the only one being returned, when there are others avail that seem to map better. For example, I get RC0x21 when I pass persist_to=100, replicate_to=100, which are values that are impossible to comply with on a 3-node cluster. In this case, I’d expect something like one of these two:

C.LCB_DURABILITY_INVALID_LEVEL: DurabilityInvalidLevelException, C.LCB_DURABILITY_IMPOSSIBLE: DurabilityImpossibleException,
from https://github.com/couchbase/couchbase-python-client/blob/master/couchbase/exceptions.py

The reason I’m posting is because currently, in order to determine if a raised exception is durability-related (as opposed to the various other reasons an ArgumentError might be raised, I have to compare the ArgumentError.rc value to 33; something like…

try:
    # insert a document
except ArgumentError as e:
    if e.rc == 33: # RC=0x21
        log.exception('Durability error - one or more Couchbase cluster nodes are [possibly down] - investigate')
        abort()

I do see that CouchbaseDurabilityError inherits from InternalSDKError (both in couchbase_core, which seems to be a hint that these are not meant to be exposed to the SDK user. But, I am rather unclear as to how the files in couchbase_core relate to the PySDK, so pardon if I’m missing something obvious.

Any insight on this? It would be useful to be able to disambiguate the different types of durability requirement violations so that my app can react in different ways.

The durability impossible has been added for some of the features in Couchbase Server 6.5, where the cluster itself can return durability impossible (see some of the blogs on the synchronous durability facility being added).

The older durability requirements for PersistTo and ReplicateTo are still consistent with their older error messages.

I agree with your need to disambiguate, but in effect there are two different features under the hood and they have different error handling paths.

Alright, fair enough. Now, with respect to durability constraint violations using PersistTo/ReplicateTo: are there any other exception classes, or return codes other than 0x21/33 for ArgumentError, that might be raised by a violation?