fix: increase assertChangelogAttributesInRootDSE retry timeout from 10s to 30s

[Copilot]

ChangelogBackendTestCase.searchInChangeNumberModeOnOneSuffixMultipleTimes is flaky on macos-latest CI runners because firstchangenumber is assigned asynchronously and the 10-second retry window in assertChangelogAttributesInRootDSE is insufficient, causing the assertion to observe 0 instead of 1.

Change

• ChangelogBackendTestCase.java — bumps maxSleep in assertChangelogAttributesInRootDSE from 10 → 30 seconds, matching the existing timeout already used by searchChangelog in the same file:

// Before
TestTimer timer = new TestTimer.Builder()
    .maxSleep(10, SECONDS)
    .sleepTimes(100, MILLISECONDS)
    .toTimer();

// After
TestTimer timer = new TestTimer.Builder()
    .maxSleep(30, SECONDS)
    .sleepTimes(100, MILLISECONDS)
    .toTimer();

Original prompt

Problem

The CI job for PR #599 is failing on the macos-latest runner due to a flaky test:

Test: ChangelogBackendTestCase.searchInChangeNumberModeOnOneSuffixMultipleTimes
File: opendj-server-legacy/src/test/java/org/opends/server/backends/ChangelogBackendTestCase.java

Error:

ChangelogBackendTestCase.searchInChangeNumberModeOnOneSuffixMultipleTimes:589->assertChangelogAttributesInRootDSE:861->assertAttributeValue:1431
firstchangenumber: 0
expected: "1"
 but was: "0"

Root Cause

The method assertChangelogAttributesInRootDSE (lines 854-890) uses a TestTimer with a 10-second timeout to poll the Root DSE for firstchangenumber and lastchangenumber. On slower environments like the macos-latest GitHub Actions runner, change number assignment happens asynchronously and 10 seconds is insufficient for firstchangenumber to transition from 0 to 1.

Other retry timers in the same file (e.g., searchChangelog at line 1124) already use 30 seconds, making the 10-second timeout in assertChangelogAttributesInRootDSE inconsistent and the likely cause of flakiness.

Fix

In opendj-server-legacy/src/test/java/org/opends/server/backends/ChangelogBackendTestCase.java, increase the maxSleep timeout in the assertChangelogAttributesInRootDSE method from 10 seconds to 30 seconds:

Before (line 857-860):

TestTimer timer = new TestTimer.Builder()
    .maxSleep(10, SECONDS)
    .sleepTimes(100, MILLISECONDS)
    .toTimer();

After:

TestTimer timer = new TestTimer.Builder()
    .maxSleep(30, SECONDS)
    .sleepTimes(100, MILLISECONDS)
    .toTimer();

This makes the timeout consistent with the other retry timer in searchChangelog (line 1124-1127) and gives enough time for the asynchronous change number assignment to complete on slower CI runners.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Please find a solution for this failing job. Use the logs, job definition, and any referenced files where the failure occurred. Keep your response focused on the solution and include code suggestions when appropriate.

Assistant:

I'll start by fetching the job logs and the workflow definition to understand the failure.

Assistant: ## Failing Test Analysis

The build is failing due to 1 actual test failure (the PostgreSQL/JDBC tests are only skipped, not failed):

Root Cause

ChangelogBackendTestCase.searchInChangeNumberModeOnOneSuffixMultipleTimes fails at line 589 with:

firstchangenumber: 0
expected: "1"
 but was: "0"
ignoring case considerations expected:<"[1]"> but was:<"[0]">

The call chain is:

1. searchInChangeNumberModeOnOneSuffixMultipleTimes (line 589)
2. → assertChangelogAttributesInRootDSE(1, 4) (line 861)
3. → assertAttributeValue(entry, "firstchangenumber", 1) (line 882 → line 1431)

What's Happening

In the test method searchInChangeNumberModeOnOneSuffixMultipleTimes (line 581–615), the first block publishes 4 changes and then asserts firstchangenumber=1. However, the firstchangenumber attribute in the Root DSE is returning 0 instead of 1, indicating the changelog's change number indexing hasn't been assigned yet by the time the assertion runs.

The method assertChangelogAttributesInRootDSE (line 854–890) already has a retry loop with a 10-second timeout, but change number assignment appears to be happening asynchronously and firstchangenumber stays at 0 even after lastchangenumber reaches the expected value.

Suggested Fix

The issue is a race condition — the firstchangenumber is checked only when expectedFirstChangeNumber > 0, but the retry loop can succeed when lastchangenumber matches while firstchangenumber is still 0. The fix is to always verify firstchangenumber within the retry loop when it's expected to be positive:

// In assertChangelogAttributesInRootDSE (line 854-890)
@Override
public List<SearchResultEntry> call() throws Exception
{
  final Set<String> attributes = new LinkedHashSet<>();
  if (expectedFirstChangeNumber > 0)
  {
    attributes.add("firstchangenumber");
  }
  attributes.add("lastchangenumber");
  attributes.add("changelog");
  attributes.add("lastExternalChangelogCookie");

  final InternalSearchOperation searchOp = searchDNWithBaseScope(DN.rootDN(), attributes);
  final List<Sear...

</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

*This pull request was created from Copilot chat.*
>