[#956] Tell a failed entryUUID search apart from an entry which is not there

[vharseko]

solveNamingConflict() decides an entry is gone by searching for its entryUUID and getting nothing back, and getFirstResult() answers the same thing for a search which found nothing and for a search which never ran:

private static SearchResultEntry getFirstResult(InternalSearchOperation search)
{
  if (search.getResultCode() == ResultCode.SUCCESS) { ... }
  return null;                       // no entry, or the search never ran
}

Every caller in conflict resolution read that null as "the entry has been deleted" and answered NOTHING_TO_DO, and that branch commits the CSN unconditionally - it never got the guard #892 added two lines below it, on case FAILED. So a change which was never applied was recorded as replayed, the replication server never sent it again because this replica reported itself past that CSN, and no alert was raised: the #889 failure mode, through a branch #892 did not harden.

What this changes

• findEntryDN() reports a search which did not run instead of answering "no entry" out of it: a non-SUCCESS result code is a SearchFailedException. One result code is looked at twice: a backend which serves the base DN and has no base entry answers NO_SUCH_OBJECT on every route (EntryContainer.searchIndexed fetches the base entry before it returns success, MemoryBackend.search checks it first) - and so does a backend which is not there. The backend itself tells the two apart, baseEntryIsAbsentFromALiveBackend(): the search ran over a backend which is there and empty, and it did not run over one which is gone or fails to answer. Without that, the base entry of a domain replayed into an empty replica - two empty replicas share the generation ID of an empty backend, so no initialization is needed and the base entry is the first change - would be retried until the give-up budget skipped it.
• The entryUUID is looked up as the value it is rather than read as part of a filter string: it comes off the wire and nothing validates it as one, and "entryuuid=" + uuid made a value which does not parse - a dangling escape - a search which never runs, retried as a transient failure for as long as the change was asked for. Looked up as a value, such an entryUUID names no entry, which is what a search which ran and found nothing says. The // never happens because the filter is always valid comment is true now.
• The replay takes the failure as the failure of the server it is: a new ConflictResolution.SEARCH_FAILED gets the in-place attempts a storage which failed gets, and the change is left out of the ServerState once they are spent, so the replication server delivers it again. The result code of the attempt says nothing of it - it is the conflict the operation failed on - so the attempt keeps the search failure and the exhaustion exit reports it, in the ERR_ERROR_REPLAYING_OPERATION line it already logs, in place of the error of the operation. Nothing is logged per attempt in place, as nothing is for a storage which failed to serve the operation: a backend which is down for a while fails every attempt of every change delivered meanwhile.
• The entryUUID searches which check a replayed Add for a conflict before it runs (handleConflictResolution(PreOperationAddOperation)) are treated the same way: the operation is stopped with UNAVAILABLE and the search which did not run as its error message, which is what the exhaustion exit reports. Reading the first of them as "not replayed here yet" adds an entry a second time when it was renamed since; reading the second as a parent which is gone hands the Add to conflict resolution as the naming conflict it is not, and renames the entry under the base DN as a conflicting entry when the search conflict resolution makes fails as well.

findEntryUUID() is deliberately left alone: a search which fails there leaves a locally originated ModifyDN published without the entryUUID of its new superior, which is a bug on what this server sends rather than on what it records. It deserves an issue of its own.

Rebased on master

The branch sits on master as it is now, which carries #948, #965 and - since the review round - #935, #959, #969, #970, #972, #973, #975, #976. The only conflict of the last rebase was replication.properties, where #959 and #972 added 326 and 327 next to this branch's 322; both sides are kept. The Java merged on its own, and #972 reads the same situation this change lets through: a suffix whose base entry is not in the backend is "what a suffix waiting to be initialized looks like", and its generationId is now left unstored rather than written to the configuration entry - StateWithoutBaseEntryTest is 3/3 on this branch.

#948 put the in-place attempt of a replayed change under the replay read lock it introduced, and
the SEARCH_FAILED retry is inside it: its 50 ms are waited where the FAILED retry of #892
already waits - a domain on its way down takes that lock exclusively and waits out the attempt in
flight, as it does for every other in-place retry.

#965 answers a ModifyDN whose entry is gone before the new superior is looked up, so
solveNamingConflict(ModifyDNOperation) reads the entryUUID search first and returns on it. A
search which did not run now leaves that method rather than being read as an entry which is gone -
it declares throws Exception, so the SearchFailedException reaches the catch in the replay
loop, which is where it is turned into SEARCH_FAILED.

Tests

Nine cases in NamingConflictTest, driven by ShortCircuitPlugin on SEARCH/PreParse. The plugin grew a registerShortCircuit(..., letThroughFirst, maxTimes) so that a failure can start part way through the searches of an attempt - the second search failing while the first ran - and every case which registers a bounded short circuit asserts, before it is deregistered (which drops the count), that the budget was spent and the search after it ran.

• modifyIsRetriedWhileTheEntryUUIDSearchCanNotRun, deleteIsRetriedWhileTheEntryUUIDSearchCanNotRun, modifyDnIsRetriedWhileTheEntryUUIDSearchCanNotRun - a change on an entry which was renamed here, so that only the entryUUID search finds it; the search fails twice and is served on the third attempt. Without the fix: NOTHING_TO_DO after a single search, the change dropped and the CSN recorded as replayed.
• addIsNotReplayedTwiceWhileTheEntryUUIDSearchCanNotRun - an Add delivered a second time whose entry was renamed since; the first search of the first attempt fails. Without the fix the entry is added a second time under its former DN, one entryUUID twice in the data.
• addIsRetriedWhileTheParentEntryUUIDSearchCanNotRun - the parent check fails while the search before it ran; pinned by the monitor: no naming conflict is counted for a search which read nothing. Without the fix conflict resolution counts one and rewrites the message to the DN it already carries.
• addIsRetriedWhileTheConflictResolutionSearchCanNotRun - the parent was renamed here, so the Add fails on a genuine conflict, and the search conflict resolution reads the data with fails. Without the fix the entry is renamed under the base DN as a conflicting entry; with it, the conflict is counted once, when it is solved.
• modifyIsLeftOutOfTheServerStateWhenTheEntryUUIDSearchNeverRuns - every attempt in place fails its search: the change is not in the ServerState and the entry untouched. This is the case which pins the exhaustion exit: with || searchFailedResolvingConflict != null removed, the exit falls into the ERR_LOOP branch and commits the CSN.
• baseEntryIsAddedToAnEmptyReplica - the base entry replayed into a backend without one. Fails on the previous head of this branch: ten UNAVAILABLE attempts, the change left out of the ServerState, no base entry.
• anEntryUUIDWhichIsNotOneNamesNoEntry - an entryUUID no filter string parses; the change is resolved as one on an entry which is not in the data, and recorded.

Mutation runs, each on the final tests: with findEntryDN() answering null for a search which did not run and the exhaustion term removed, seven of the nine fail (baseEntryIsAddedToAnEmptyReplica and the filter case are the two that behaviour does not reach); with the two catches of the Add hook reverted to "no entry" and everything else kept, addIsNotReplayedTwice... fails on the duplicate entry and addIsRetriedWhileTheParent... on the conflict counted.

NamingConflictTest is 17/17 at 5ab2187. The org.opends.server.replication.** package ran on the review-round commit before the rebase: 3595 tests with 2 failures, both setUp of an embedded server which did not get the admin port it binds (Address already in use on 65534 and 65530 - test servers of other checkouts on the same machine), which took the 65 methods of ProtocolCompatibilityTest and FileChangeNumberIndexDBTest into skipped; on the rebased tree the two classes are 58/58 and 5/5, and NamingConflictTest 17/17 again.

Not in this change

• A change which never applied is recorded as replayed when server-error-result-code is set to NO_OPERATION or SUCCESS #953 - SUCCESS, NO_OPERATION and BUSY being read before either guard is consulted.
• NPE in solveNamingConflict(ModifyDNOperation) when both the moved entry and its new parent are gone #955 - the NPE in solveNamingConflict(ModifyDNOperation) when both the moved entry and its new parent are gone: fixed on master by [#955] Answer a ModifyDN whose entry is gone before the new superior is looked up #965, which this branch sits on. What this change adds there is that a search which did not run no longer reaches that decision at all.
• The second half of A failed entryUUID search reads as a deleted entry, and conflict resolution records the change as replayed #956: case NOTHING_TO_DO refusing to commit the CSN while the result code is the configured server-error-result-code. With the search telling a failure from an empty answer, NOTHING_TO_DO is only reached when the search did run and the entry really is not in the data, and the guard would refuse legitimate no-ops - a Modify on an entry genuinely deleted elsewhere would be retried until the give-up budget raised a false "this replica diverged" alert.

Fixes #956

Ordinal

ERR_REPLAY_ENTRYUUID_SEARCH_FAILED_322, moved off 310 in 4110d0c and renamed from WARN_ once it stopped being logged on its own: it is the error message of the operation the Add hook stops, and the error the exhaustion exit reports. Six open branches had each read
310 as the first ordinal free in master and taken it, and git merges those additions without
reporting a conflict - they land in different places in the file - so the duplicate would only have
surfaced afterwards, as two unrelated messages sharing one support ID. The generator does not check
either: it keys on name and ordinal together, so both compile. The open PRs which add to
replication.properties now hold 310-325 with nothing claimed twice.

[vharseko]

Ordinal moved: WARN_REPLAY_ENTRYUUID_SEARCH_FAILED 310 → 322 (4110d0c).

Six open branches had each read 310 as the first ordinal free in master and taken it - #935, #945,
#959, #964, #968, #977.

Nothing catches this on the way in. The additions land in different parts of the file, so git merges
every pair of them without reporting a conflict - I merged all ten onto master to check, and the
result carried 310, 311, 315 and 316 twice each. The generator does not check either: it loads the
file into a Properties and keys on name and ordinal (MessagePropertyKey.compareTo), so both
sides compile. What comes out is two unrelated messages carrying one support ID, found by whoever
reads a log rather than by CI.

The open PRs which add to the file now hold 310-325 with nothing claimed twice:

310-313 #935 · 314 #959 · 315-317 #958, #985 · 318 #985, #988 · 319-320 #945 · 321 #964 ·
322 #968 · 323-324 #977 · 325 #981

No Java moved with it: the generated constant is the key name without its ordinal, so the rename is
confined to replication.properties. #935, #958 and #985 keep what they had.

[vharseko]

Rebased on master; the conflict was #948 moving the block this change rewrites (bdb4f49)

Master carries #948 now, which put the whole in-place attempt of a replayed change - building the
operation, running it, and the conflict resolution which follows a failure - under the replay read
lock that change introduced. This branch rewrites the same block where it used to be, so git kept
both copies side by side rather than merging them: the same code, in two places, neither of them
wrong on its own.

Resolved by dropping the copy this branch carried and applying its three edits to the block where
#948 put it:

• the dispatch to solveNamingConflict() wrapped in try / catch (SearchFailedException), which
  logs WARN_REPLAY_ENTRYUUID_SEARCH_FAILED and answers SEARCH_FAILED;
• case SEARCH_FAILED ahead of case FAILED, which marks the attempt and waits 50 ms;
• default clearing that mark, so the verdict below the loop reads the attempt which ended it.

The 50 ms are now waited holding the replay read lock, which is where the FAILED retry of #892
already waits: a domain on its way down takes that lock exclusively and waits out the attempt in
flight, whichever retry it is.

replication.properties conflicted for a plainer reason - #945 and #948 added 319 and 320 where
this branch adds its message. Both sides are kept and 322 is still nothing else's.

The diff is the same 270 insertions / 37 deletions over the same three files as before the rebase,
and NamingConflictTest is 9/9 on it. The org.opends.server.replication.** package is being run
again on the rebase; the description carries the numbers of the run made before it until then.

[vharseko]

Rebased again, on master with #965 (d68a79c)

#965 landed while this was waiting, and it reads the same entryUUID search this change is about:
solveNamingConflict(ModifyDNOperation) now answers a ModifyDN whose entry is gone before the new
superior is looked up. The two fit without either giving anything up - the Java merged on its own -
and the shape is the one this change wants: the search is read first, and a search which did not
run leaves the method rather than being answered as an entry which is gone. solveNamingConflict
declares throws Exception, so the SearchFailedException reaches the catch in the replay loop,
which turns it into SEARCH_FAILED - the retry, not the NOTHING_TO_DO which would have recorded
the change as replayed.

The conflict was in NamingConflictTest: #965 and this branch each added a test at the same place
in the file. Both are kept - modifyDnOnAnEntryAndANewSuperiorWhichAreBothGone from #965, then the
two from this branch - and the class is 10/10.

The diff is unchanged at 270 insertions / 37 deletions over the same three files. The
org.opends.server.replication.** package is being run again on this base; the description carries
the numbers of the run made before #965 until it finishes.

The #955 line under "Not in this change" is updated: that NPE is fixed on master now, by #965.
What this change adds there is that a search which did not run no longer reaches the decision at
all.

[maximthomas]

praise: the fix is small and lands where the read happens.

SearchFailedException is thrown at the one site that reads the data (findEntryDN),
every caller either answers SEARCH_FAILED or stops the pre-op with UNAVAILABLE, and the
replay loop needs one flag on top of the server-failure retry it already had. NamingConflictTest
is 10/10 at HEAD, and the OOME / alert contract below the loop is untouched. The comments at
LDAPReplicationDomain.java:2876-2894 and the PR body state the deliberate choices (the parse
failure retried, the error naming the conflict code) instead of leaving the reader to guess, and
ShortCircuitPlugin with a bounded maxTimes is the right tool for "fails, then serves again".

---

opendj-server-legacy/src/main/java/org/opends/server/replication/plugin/LDAPReplicationDomain.java:3524

issue (blocking): findEntryDN() now throws on NO_SUCH_OBJECT, so a replayed Add of the
domain base entry into an empty replica never lands.

Two empty replicas share EMPTY_BACKEND_GENERATION_ID (48), so no initialize is needed and the
first change replayed is the base entry itself. Its pre-op hook runs findEntryDN(uuid) at
:1856, before the parentEntryUUID == null short-cut at :1875. A backend that serves the base
DN but has no base entry answers NO_SUCH_OBJECT on every route (EntryContainer.fetchBaseEntry);
there is no "SUCCESS with zero entries" path. At BASE that was null -> the Add went through. At
HEAD it is SearchFailedException -> UNAVAILABLE -> 10 attempts -> redeliveries until
replay-give-up-delay (300 s) -> the change is skipped with a "replica diverged" alert.

The same code comes back when no backend serves the DN (SearchOperationBasis:1211,
backend offline or being rebuilt), which is the case this PR must keep catching — so a bare
NO_SUCH_OBJECT whitelist would reopen #956. Ask the backend instead:

if (search.getResultCode() != ResultCode.SUCCESS)
{
  if (search.getResultCode() == ResultCode.NO_SUCH_OBJECT && baseEntryIsAbsentFromALiveBackend())
  {
    // The backend serves the base DN and has no base entry yet: the search ran, and nothing
    // is below a base entry which is not there. This is the empty replica about to receive it.
    return null;
  }
  throw new SearchFailedException(uuid, ...);
}

private boolean baseEntryIsAbsentFromALiveBackend()
{
  final LocalBackend<?> backend =
      getServerContext().getBackendConfigManager().findLocalBackendForEntry(getBaseDN());
  if (backend == null)
  {
    return false; // nothing serves the DN: offline or being rebuilt - the search did not run
  }
  try
  {
    return !backend.entryExists(getBaseDN());
  }
  catch (DirectoryException e)
  {
    return false; // the storage failed to answer - the search did not run
  }
}

And a test that would have caught it — no test in src/test/.../replication replays the
base-entry AddMsg into a backend without one:

@Test
public void baseEntryIsAddedToAnEmptyReplica() throws Exception
{
  TestCaseUtils.initializeTestBackend(false); // the backend, without its base entry
  final Entry base = TestCaseUtils.makeEntry("dn: " + TEST_ROOT_DN_STRING,
      "objectClass: top", "objectClass: organization", "o: test");
  final CSN csn = gen.newCSN();

  replayMsg(addMsg(base, csn, null, "7c1a0d2e-4b6f-4c8a-9e1d-3f5b7a9c1e2d"));

  assertTrue(DirectoryServer.entryExists(base.getName()),
      "the base entry of an empty replica must land: its search found nothing, it did not fail");
  assertTrue(domain.getServerState().cover(csn));
}

---

opendj-server-legacy/src/main/java/org/opends/server/replication/plugin/LDAPReplicationDomain.java:2899

issue (blocking): the exhaustion exit — || searchFailedResolvingConflict, the half of the
fix that closes #889 — is pinned by no test.

Both new cases fail the search 2 and 3 times against a budget of 10 and then succeed, so the loop
leaves on replayDone and the gate is never reached with this flag as the deciding term. Measured:
with the term removed, NamingConflictTest is still 10/10; with the whole case SEARCH_FAILED
arm deleted (falls into default:), still 10/10. A regression of the exact #889 shape — attempts
spent, CSN committed, change lost — passes CI.

@Test
public void modifyIsLeftOutOfTheServerStateWhenTheEntryUUIDSearchNeverRuns() throws Exception
{
  final Entry entry = createAndAddEntry("modifyWhoseSearchNeverRuns");
  final String entryUUID = getEntryUUID(entry.getName());
  final DN staleDN = DN.valueOf("cn=movedAway," + TEST_ROOT_DN_STRING);
  final CSN csn = gen.newCSN();

  // No maxTimes: every attempt in place fails its search.
  ShortCircuitPlugin.registerShortCircuit(OperationType.SEARCH, "PreParse", ResultCode.UNAVAILABLE.intValue());
  try
  {
    replayMsg(new ModifyMsg(csn, staleDN, generatemods("telephonenumber", "01 02 45"), entryUUID));
  }
  finally
  {
    ShortCircuitPlugin.deregisterShortCircuit(OperationType.SEARCH, "PreParse");
  }

  assertFalse(domain.getServerState().cover(csn),
      "a change whose search never ran is not in the data and must not advance the ServerState");
  assertTrue(ShortCircuitPlugin.getShortCircuitCount(OperationType.SEARCH, "PreParse") >= 10,
      "every attempt in place must have made its search");
}

This assert kills the mutant: without the term the gate falls into the ERR_LOOP branch at
:2913-2924, which commits the CSN. (The exit requests a session restart; the fixture has no
replication server, so if that blocks, replay with a shutdown flag set to true so
runRequestedSessionRestarts(false) returns at once.)

---

opendj-server-legacy/src/test/java/org/opends/server/replication/plugin/NamingConflictTest.java:328

issue (blocking): this comment, and the PR's "searches ... are treated the same way",
describe a flow the test does not run; the parent-search catch at
LDAPReplicationDomain.java:1884-1887 is never reached.

Every attempt makes the first findEntryDN(uuid) at :1856; under the short circuit it fails and
the hook returns before :1882. maxTimes=3 is three attempts, one failed search each; the
fourth attempt passes every search. Measured: reverting the parent catch to BASE semantics
(parentDnFromCtx = null) keeps the class 10/10. Of the three new production lines in the hook the
test sees one.

Minimum: fix the comment (one search per attempt, the first one) and the PR text, and say the
parent catch is pinned by symmetry with :1858, not by a test. ShortCircuitPlugin cannot select
by filter, so pinning the parent search itself needs a skip-first-N short circuit or a filter-aware
one — worth it only if the plugin grows that anyway.

---

opendj-server-legacy/src/main/java/org/opends/server/replication/plugin/LDAPReplicationDomain.java:2765

suggestion (non-blocking): WARN_REPLAY_ENTRYUUID_SEARCH_FAILED is logged once per attempt
in place — up to 10 lines per delivery, plus 10 more for every redelivery
(WARN_REPLAY_RETRYING_CHANGE at :3296 is one per delivery). The sibling isServerFailure arm
at :2692 logs nothing per attempt. A backend offline for the whole 300 s budget on a busy domain
is changes x 10 x redeliveries lines. Log once per delivery — on the first SEARCH_FAILED, or at
the exhaustion exit where the failure is already reported.

---

opendj-server-legacy/src/test/java/org/opends/server/replication/plugin/NamingConflictTest.java:291

suggestion (non-blocking): neither new case checks that the short circuit fired. A run where
it never does (plugin not loaded in the fixture, search routed elsewhere) stays green on the
sibling assertions. One line per case, after deregisterShortCircuit:

// The count includes the searches let through once maxTimes was spent: > 2 says the
// budget was used and the search after it ran.
assertTrue(ShortCircuitPlugin.getShortCircuitCount(OperationType.SEARCH, "PreParse") > 2,
    "the short circuit must have been spent by the attempts in place");

---

opendj-server-legacy/src/main/java/org/opends/server/replication/plugin/LDAPReplicationDomain.java:2756

suggestion (non-blocking): the SearchFailedException -> SEARCH_FAILED switch serves all
four conflict resolutions, but only Modify and Add have a case; Delete and ModifyDN are pinned by
nothing. Same mechanism, so low risk — either one case each (a DeleteMsg / ModifyDNMsg on a
stale DN with maxTimes=2, same assertions as the Modify case), or a sentence in the PR saying
they ride on the shared switch.

---

opendj-server-legacy/src/main/java/org/opends/server/replication/plugin/LDAPReplicationDomain.java:3517

note (non-blocking): a filter that does not parse is a permanent condition retried as a
transient one — 10 attempts, then redeliveries until the give-up budget, for an entryUUID that
will never parse. The PR body says this is deliberate and the cost is bounded, so nothing to
change; only noting that this branch is reached by no test, and that the unescaped
"entryuuid=" + uuid it guards is pre-existing.

[vharseko]

Review round 1 addressed (68cff84)

• findEntryDN() throws on NO_SUCH_OBJECT, the base entry of an empty replica never lands - confirmed, and the shape is as described: EntryContainer.searchIndexed fetches the base entry before it returns success with nothing sent, MemoryBackend.search checks it first, and LocalBackendWorkflowElement.execute answers the same code when no backend serves the DN. Fixed with baseEntryIsAbsentFromALiveBackend() in findEntryDN(), asked of the backend as suggested (getBackend() was already there). baseEntryIsAddedToAnEmptyReplica fails on d68a79c - ten UNAVAILABLE attempts, no base entry - and passes now.

• The exhaustion exit is pinned by no test - modifyIsLeftOutOfTheServerStateWhenTheEntryUUIDSearchNeverRuns added; with the term removed it fails on the CSN committed, as measured. Two things in the sketch did not survive contact with the fixture: deregisterShortCircuit() drops the count with the registration, so the count is asserted before the finally; and a shutdown flag set to true is read before the first attempt (replay() abandons the change at once), so the test runs with SHUTDOWN false and takes the 1 s session-restart wait - 2 s for the method.

• The Add test comment describes a flow it does not run - it did, and worse: with maxTimes short of the conflict-resolution search the old test passed with findEntryDN() answering null for a failed search, because conflict resolution's own search re-read the parent. ShortCircuitPlugin grew registerShortCircuit(..., letThroughFirst, maxTimes), and the Add is now three cases, each pinning one search: addIsNotReplayedTwiceWhileTheEntryUUIDSearchCanNotRun (the first search; the harm is a second copy of a renamed entry), addIsRetriedWhileTheParentEntryUUIDSearchCanNotRun (the parent check; pinned by the monitor - no naming conflict counted for a search which read nothing, which is the one thing that tells the hook's catch from conflict resolution re-reading the parent), and addIsRetriedWhileTheConflictResolutionSearchCanNotRun (the search after a genuine conflict; the parent was renamed here). A run with both hook catches reverted and everything else kept fails the first two.

• One WARN per attempt in place - nothing is logged per attempt now, as nothing is for a storage which failed to serve the operation. The attempt keeps the SearchFailedException, and the exhaustion exit reports it in the ERR_ERROR_REPLAYING_OPERATION line it already logs, in place of the error of the operation - which for this case only named the conflict. The Add hook puts the same text on the operation it stops, so that path reaches the exit line the same way. The message is ERR_REPLAY_ENTRYUUID_SEARCH_FAILED_322 now that it is never logged on its own; the ordinal stays.

• Neither new case checks that the short circuit fired - every case with a bounded short circuit asserts, before deregistering, that the count went past the budget: the searches were made and the one after the budget ran.

• Delete and ModifyDN pinned by nothing - deleteIsRetriedWhileTheEntryUUIDSearchCanNotRun and modifyDnIsRetriedWhileTheEntryUUIDSearchCanNotRun added, the ModifyDN one because solveNamingConflict(ModifyDNOperation) throws through a throws Exception rather than a declaration which names the failure.

• A filter that does not parse is retried as transient - taken further than noting it: the entryUUID is looked up as a value now (SearchFilter.createEqualityFilter), so there is no filter string to parse and no branch left. anEntryUUIDWhichIsNotOneNamesNoEntry replays a change whose entryUUID carries a dangling escape - the one thing a simple filter string refuses - and expects it resolved as a change on an entry which is not in the data; on d68a79c it was retried until the attempts were spent. For the record, the wildcard case is not a hole: UUID syntax has no substring matching rule, so entryuuid=abcd* matched nothing either way.

[vharseko]

Rebased on master; the conflict was replication.properties (5ab2187)

Nine commits landed on master since the review round. The only conflict was in replication.properties: #959 and #972 added 326 and 327 where this branch adds 322 - both sides are kept, and 322 is still nothing else's. The Java merged on its own; the review-round commit carries the same diff on the new base as it did on the old one, line for line.

#972 is worth a note, since it reads the same situation the review's first point is about: a domain whose base entry is not in the backend now leaves its generationId unstored until the entry appears, rather than write it to the configuration entry. The base entry of an empty replica is what this branch lets land, and StateWithoutBaseEntryTest from #972 is 3/3 here.

On the rebased tree: NamingConflictTest 17/17, and the two classes which lost the admin port to another checkout's test server in the package run - ProtocolCompatibilityTest 58/58, FileChangeNumberIndexDBTest 5/5. The package run itself, made on the review-round commit before the rebase, was 3595 tests with those two setUp collisions as its only failures; the numbers are in the description.