ds-cfg-server-error-result-code is configurable and is not validated as a result code, so it can be set to a code conflict resolution owns. #892 (issue #889) made the replay handle that, and one half of it has no test.
The rule
opendj-server-legacy/src/main/java/org/opends/server/replication/plugin/LDAPReplicationDomain.java
private static final Set<ResultCode> CONFLICT_RESULT_CODES = ... // :407
ResultCode.NO_SUCH_OBJECT, ResultCode.ENTRY_ALREADY_EXISTS,
ResultCode.NOT_ALLOWED_ON_RDN, ResultCode.NOT_ALLOWED_ON_NONLEAF,
// solveNamingConflict(ModifyDNOperation) solves these two as well
ResultCode.UNWILLING_TO_PERFORM, ResultCode.OBJECTCLASS_VIOLATION);A change which fails with the configured code is left to solveNamingConflict() when that code is one of these - conflict resolution is the only thing which can solve them - and is treated as a failure of the server only once conflict resolution reports it could not (isConfiguredServerErrorResultCode(), :2795).
What is covered and what is not
- Covered:
UpdateOperationTest.changeConflictResolutionCanNotSolveOnTheServerErrorCodeIsRetried sets the code to 53 (UNWILLING_TO_PERFORM) and asserts that a Delete which keeps failing with it is retried and applied rather than recorded as replayed.
- Not covered: that a naming conflict which
solveNamingConflict(ModifyDNOperation) does solve is still solved with that setting in place. UNWILLING_TO_PERFORM and OBJECTCLASS_VIOLATION were added to the set for the ModifyDN overload specifically, and nothing exercises that combination - the test above would pass with those two entries removed, because the code then routes through isServerFailure() and is retried anyway.
What is needed
A test which, with ds-cfg-server-error-result-code set to 53 (and a second run at 65), replays a ModifyDN whose conflict solveNamingConflict(ModifyDNOperation) resolves through those result codes, and asserts the entry ends up where conflict resolution puts it - not retried as a server failure and not skipped. NamingConflictTest / UpdateOperationTest.namingConflicts are the closest existing scenarios to build it from.
Low severity: it guards a non-default configuration. It is listed here so the gap is recorded rather than rediscovered.
ds-cfg-server-error-result-codeis configurable and is not validated as a result code, so it can be set to a code conflict resolution owns. #892 (issue #889) made the replay handle that, and one half of it has no test.The rule
opendj-server-legacy/src/main/java/org/opends/server/replication/plugin/LDAPReplicationDomain.javaA change which fails with the configured code is left to
solveNamingConflict()when that code is one of these - conflict resolution is the only thing which can solve them - and is treated as a failure of the server only once conflict resolution reports it could not (isConfiguredServerErrorResultCode(),:2795).What is covered and what is not
UpdateOperationTest.changeConflictResolutionCanNotSolveOnTheServerErrorCodeIsRetriedsets the code to 53 (UNWILLING_TO_PERFORM) and asserts that a Delete which keeps failing with it is retried and applied rather than recorded as replayed.solveNamingConflict(ModifyDNOperation)does solve is still solved with that setting in place.UNWILLING_TO_PERFORMandOBJECTCLASS_VIOLATIONwere added to the set for the ModifyDN overload specifically, and nothing exercises that combination - the test above would pass with those two entries removed, because the code then routes throughisServerFailure()and is retried anyway.What is needed
A test which, with
ds-cfg-server-error-result-codeset to 53 (and a second run at 65), replays a ModifyDN whose conflictsolveNamingConflict(ModifyDNOperation)resolves through those result codes, and asserts the entry ends up where conflict resolution puts it - not retried as a server failure and not skipped.NamingConflictTest/UpdateOperationTest.namingConflictsare the closest existing scenarios to build it from.Low severity: it guards a non-default configuration. It is listed here so the gap is recorded rather than rediscovered.