The server and network suites still bound wall clock the way the engine suite did before #6260

[lvca]

Follow-up to #6260 / #6268, raised in that PR's review.

#6260 fixed the engine suite: 44 elapsed-time assertions now measure through StallAwareStopwatch, which discounts the JVM-wide stall (stop-the-world pauses and CPU starvation) observed inside the measured window, so a bound can stay tight without being tripped by a pause late in a shared-JVM run.

The same flake mode applies to every other module that runs a suite in one JVM, and those were deliberately left out of the scope of that PR. grep over server/src/test/java and network/src/test/java turns up:

server/.../Issue5470BatchStreamStallIT.java
server/.../HTTPAuthSessionIT.java              (2 sites)
server/.../Issue5470BatchErrorDeliveryIT.java
server/.../PostBatchHandlerIT.java
server/.../Issue5418ShutdownHookDeadlockTest.java
network/.../RemoteHttpComponentTest.java

The server module is a worse environment for this than the engine one, not a better one: its tests bind real ports, start real servers and talk HTTP, so they already sit closer to their bounds, and Issue5470BatchStreamStallIT is a known-red lane.

What to do

StallAwareStopwatch and JvmStallMonitor live in the engine test-jar, which server and network already consume for TestHelper, so nothing needs moving - the work is per-assertion classification, the same pass #6268 did:

1. Bounding a named timeout - a tripwire between a bounded operation and an unbounded one. assertGaveUpWithin; generous is free, because a wider bound cannot turn a passing run red.
2. A complexity claim - the bound IS the assertion and has no other practical expression. assertStayedUnder; loosening it deletes the test.
3. A lower bound, or a short wait expected to time out - leave alone. A stall only makes those more true.

@Timeout also wants a look while in there: it is plain wall clock, JUnit gives no way to discount it, so it has to be sized as a hang detector rather than as a latency bound.

The rule is written up in CLAUDE.md under the testing guidance.

Worth checking while doing it

The engine pass found its 44 sites with a grep for assertThat(elapsed…), which missed four more that assert on the expression inline or name the local something else - one of them being a test named in the original issue as a motivating failure. Sweep on System.currentTimeMillis() - / System.nanoTime() - instead, and expect to filter out printlns and @Tag("benchmark") classes by hand.

[lvca]

Widening the scope of this follow-up, from a review point on #6268: the @Timeout annotations need the same per-assertion classification pass as the elapsed-time bounds, and not just in server/network.

@Timeout is plain wall clock and JUnit gives no way to discount a stop-the-world pause, so a 24s or 27s stall of the kind #6260 was filed on trips it on a run where nothing was wrong. #6268 raised four of them - the ones on tests it had already touched, whose own honest budget was close enough to the observed stalls to matter - and left the rest alone on purpose.

The rest is about twenty annotations in the engine suite alone at 45s or under:

RangeFunctionTest                    5s x8, 10s x3
IndexDescOrderDuplicateKeysTest      10s
LongRangeListTest                    10s
LongObjectHashMapTest                20s x2
HashIndexOverflowCycleTest           30s x2
CypherRangeHeapExhaustionTest        30s x3
LockManagerFairnessTest              30s x7, 60s x3

Bumping them all would be exactly the blanket widening #6268 argues against, because they are not all the same kind of bound. RangeFunctionTest's 5s annotations are the GHSA-xmjm range() guard: the whole claim is that the call returns instead of materialising the range, so the timeout IS the assertion and widening it weakens the security regression test. LockManagerFairnessTest's, by contrast, look like plain hang detectors on tests whose real budget is a second or two.

So the pass is the same three-way split as the elapsed-time one:

1. A hang detector - size it well clear of the honest budget plus a ~30s stall. Generous is free.
2. The assertion itself - leave the value alone, and if the honest budget is genuinely close to the bound, express the claim with a stall-discounted StallAwareStopwatch assertion inside the body and let the annotation become the hang detector behind it.
3. Already generous - nothing to do.

[lvca]

One trap to know about before adopting StallAwareStopwatch outside engine, found after #6268 merged.

The sampler thread is named arcadedb-test-stall-monitor. That name sits inside the prefix DatabaseLifecycleBackgroundThreadsTest scans when it hunts for leaked engine threads:

if (name.startsWith("ArcadeDB") || name.startsWith("AsyncExecutor-") || name.startsWith("arcadedb-"))
  nonDaemon.add(t);

It does not trip today, and only for one reason: that loop skips daemons first, and the sampler is a daemon. So the utility is safe as merged.

But it is one edit away from not being safe. The obvious future change to this class is giving it a shutdown path - the #6268 review raised exactly that for reuse in a longer-lived process, and its Javadoc says so. Any change that makes the sampler non-daemon turns DatabaseLifecycleBackgroundThreadsTest red with "An engine background thread that is not a daemon keeps the embedder's JVM alive forever (issue #5418)", pointing at a test utility that has nothing to do with #5418 or the engine's lifecycle. That is a genuinely confusing hour for whoever hits it.

Worth doing while migrating the other modules, since server has its own thread-scanning tests (ServerJvmLivenessTest, ServerMetricsLifecycleTest) and this gets more likely with every one:

• move the sampler out of the engine's thread namespace so a leak detector cannot mistake it for engine machinery, and
• if a shutdown path is added, do it in the same change rather than separately.