Summary
com.arcadedb.graph.ConcurrentEdgeAppendMergeTest.concurrentAppendsAndRemovesStayConsistent failed once during a large batch run with:
expected: 3000L
but was: 3001L
Suppressed: AssertionFailedError: expected: 0 but was: 1 (TestHelper.checkDatabaseIntegrity)
It then passed 3/3 in isolation and in a full 326-test run of com.arcadedb.graph.**, so it reproduces only under concurrent load from the rest of the suite.
Why this is worth a look rather than a retry annotation
The count is one too many, not one too few, and checkDatabaseIntegrity flagged a problem alongside it. A lagging read would under-count; an over-count after concurrent appends and removes is the signature of an edge that was appended twice, or removed and left reachable - which is the exact class of bug the edge-append merge path (#5596, #5608, #5569) exists to prevent. It may well be a test-side race in how the expected total is computed, but that should be established rather than assumed, because the alternative is a real merge defect that only shows under contention.
Suggested first step: capture the integrity-check detail on failure (which bucket/RID is the extra one) rather than only the count, so the next occurrence says whether the surplus edge is a duplicate append or a survivor of a remove.
Reproduced once on the issue-5636 branch, which touches no graph or edge code; the surrounding suites were green.
Found while working on #5636.
Summary
com.arcadedb.graph.ConcurrentEdgeAppendMergeTest.concurrentAppendsAndRemovesStayConsistentfailed once during a large batch run with:It then passed 3/3 in isolation and in a full 326-test run of
com.arcadedb.graph.**, so it reproduces only under concurrent load from the rest of the suite.Why this is worth a look rather than a retry annotation
The count is one too many, not one too few, and
checkDatabaseIntegrityflagged a problem alongside it. A lagging read would under-count; an over-count after concurrent appends and removes is the signature of an edge that was appended twice, or removed and left reachable - which is the exact class of bug the edge-append merge path (#5596, #5608, #5569) exists to prevent. It may well be a test-side race in how the expected total is computed, but that should be established rather than assumed, because the alternative is a real merge defect that only shows under contention.Suggested first step: capture the integrity-check detail on failure (which bucket/RID is the extra one) rather than only the count, so the next occurrence says whether the surplus edge is a duplicate append or a survivor of a remove.
Reproduced once on the
issue-5636branch, which touches no graph or edge code; the surrounding suites were green.Found while working on #5636.