I wonder why to put the attribute to this check if we don't benefit from that?

We should either remove it from here or we should add this (or something like this with LDAP_UNWILLING_TO_PERFORM) to ldap/servers/slapd/libglobs.c::config_set_num_listeners:

        if (nValue > maxVal) {
            nValue = maxVal;
            retVal = LDAP_UNWILLING_TO_PERFORM;
        } else {
            retVal = LDAP_OPERATIONS_ERROR;
        }

Or do I miss something?

The check is here to cover the corner case where a user has changed version, if we don't add the check and the "nsslapd-numlisteners" attr is present in dse.ldif the instance will fail to start.

IIUC we need to return LDAP_OPERATIONS_ERROR when an invalid value has been used for this attr, otherwise the invalid value gets written to dse.ldif.

I had a look over this again and yes, it is best to return LDAP_UNWILLING_TO_PERFORM when an invalid value for the nsslapd-numlisteners is used.

Okay, IIUC, you changed the behaviour now to reject the value instead of normalizing it (as it was before).
Could you please elaborate on why you think it's the current thing to do for nsslapd-numlisteners?

You probably need to change the commit message and test the docstring with the explanation.

When the dse backend callback is called there are two passes done for each mod, the first pass validates the value and the second pass apply's the change. With the existing behaviour, when an invalid value is input the config code normalises the value during the first pass, then during the second pass the invalid value is written to dse.ldif, which is why this issue was created.

To avoid this we need to reject an invalid value so the second pass doesn't apply the change. To reject the invalid value we need to return either LDAP_OPERATIONS_ERROR like almost all of the other config_set functions or LDAP_UNWILLING_TO_PERFORM.

Yes the plan was to update the commit message during merge, I need to update the CI test so I will update the doc string also.