From cc43835e2346994b3e5561292f86528eb3f703d5 Mon Sep 17 00:00:00 2001 From: Valera V Harseko Date: Fri, 21 Aug 2026 09:36:48 +0300 Subject: [PATCH] Wait for the renamed entry before reading the naming conflict monitor UpdateOperationTest.namingConflicts cleans up after the two-adds-one-DN case by publishing a delete for each entry and then waiting for each DN to go. Both entries were created with the same DN, though - personWithSecondUniqueID is built at user1dn, the DN of personWithUUIDEntry - and the conflicting one has since been renamed to "entryuuid= + user1dn". So both waits watch user1dn and both return the moment the first delete is replayed; nothing waits for the second. That second delete is the one with a conflict to solve. Its DN holds no entry any more, so solveNamingConflict(DeleteOperation) finds the renamed one by entryUUID and counts a resolved naming conflict before replaying the delete against the new DN. The next section snapshots that counter with updateMonitorCount() and asserts a delta of 1 for the conflict it raises itself, so a count that arrives late is read as its own: "expected [1] but found [2]", as on JDK 25 in run 32375391745. Wait for the DN the rename gave the entry instead. The count is taken before the replayed delete, so an entry gone from that DN means the count is already in the monitor. --- .../org/opends/server/replication/UpdateOperationTest.java | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/opendj-server-legacy/src/test/java/org/opends/server/replication/UpdateOperationTest.java b/opendj-server-legacy/src/test/java/org/opends/server/replication/UpdateOperationTest.java index d973d2d136..4c9dde1fa5 100644 --- a/opendj-server-legacy/src/test/java/org/opends/server/replication/UpdateOperationTest.java +++ b/opendj-server-legacy/src/test/java/org/opends/server/replication/UpdateOperationTest.java @@ -729,7 +729,11 @@ public void namingConflicts() throws Exception assertNull(getEntry(personWithUUIDEntry.getName(), 10000, false), "The DELETE replication message was not replayed"); - assertNull(getEntry(personWithSecondUniqueID.getName(), 10000, false), + // The second entry was created with the same DN as the first one, so waiting + // on that DN again returns as soon as the first delete is replayed. Wait on + // the DN the naming conflict renamed it to instead: the second delete then + // has resolved its conflict, and counted it, before the monitor is read below. + assertNull(getEntry(dn2, 10000, false), "The DELETE replication message was not replayed"); /* * Check that and added entry is correctly added below it's