fix: scale Gremlin concurrent test threads to available processors

[robfrank]

Summary

• GremlinMergeVConcurrentTest and GremlinMergeVStressTest hardcoded thread counts (8 and 12) causing CI failures on GitHub runners with only 2 vCPUs
• Replaced with Math.max(2, Runtime.getRuntime().availableProcessors()) to scale to the machine's capacity while still guaranteeing concurrent execution
• Matches the pattern already used by RemoteGremlinFactoryIT and AbstractGremlinServerIT

Test plan

• CI passes on GitHub runners (2 vCPUs)
• Verify tests still exercise concurrency on developer machines with more cores

🤖 Generated with Claude Code

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the robustness of Gremlin concurrent tests by making their thread counts adaptive to the execution environment. By dynamically scaling the number of threads based on available processors, it resolves issues encountered in resource-constrained CI environments while maintaining effective concurrency testing on more powerful developer machines.

Highlights

• Dynamic Thread Scaling: Replaced hardcoded thread counts (8 and 12) in GremlinMergeVConcurrentTest and GremlinMergeVStressTest with Math.max(2, Runtime.getRuntime().availableProcessors()).
• CI Stability: The change addresses CI failures on GitHub runners with limited vCPUs by ensuring test concurrency scales appropriately to the available machine capacity.
• Consistency: This pattern aligns with existing implementations in RemoteGremlinFactoryIT and AbstractGremlinServerIT.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Changelog

• gremlin/src/test/java/com/arcadedb/server/gremlin/GremlinMergeVConcurrentTest.java
  • Changed the nOfThreads variable from a fixed value of 8 to a dynamic calculation using Math.max(2, Runtime.getRuntime().availableProcessors()).
• gremlin/src/test/java/com/arcadedb/server/gremlin/GremlinMergeVStressTest.java
  • Changed the nOfThreads variable from a fixed value of 12 to a dynamic calculation using Math.max(2, Runtime.getRuntime().availableProcessors()).

Activity

• No human activity has been recorded on this pull request yet.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

The pull request addresses an issue with hardcoded thread counts in concurrent tests, which caused CI failures on machines with fewer CPU cores. The change to dynamically scale the number of threads based on available processors is a good solution. My feedback focuses on a small improvement to reduce code duplication.

[gemini-code-assist]

This logic to determine the number of threads is also used in GremlinMergeVStressTest.java. To avoid code duplication, consider extracting this logic into a protected helper method in the common base class AbstractGremlinServerIT. This will improve maintainability.

For example, you could add this to AbstractGremlinServerIT:

protected int getConcurrentTestThreadCount() {
    return Math.max(2, Runtime.getRuntime().availableProcessors());
}

Then you can call this method from both test classes.

[mergify]

🧪 CI Insights

Here's what we observed from your CI run for 7d28087.

🟢 All jobs passed!

But CI Insights is watching 👀

[claude]

The core fix is correct and well-motivated: replacing hardcoded thread counts (8 and 12) with Math.max(2, Runtime.getRuntime().availableProcessors()) correctly handles CI runners with limited vCPUs while preserving concurrency on developer machines. The pattern is already established in RemoteGremlinFactoryIT and AbstractGremlinServerIT, so this is a consistent change.

Minor issues worth noting (pre-existing, not introduced by this PR):

1. System.out / System.err calls — Both test files have numerous debug print statements. Per project guidelines, debug System.out calls should be removed — they are noise in CI output and were presumably left over from initial development.

2. Mislabeled backoff in GremlinMergeVStressTest — The retry logic uses Thread.sleep(10 * attempt) with a comment "Exponential backoff", but this is linear backoff (10ms, 20ms, 30ms...). True exponential would be 10L << attempt. Not a blocker, but the misleading comment could confuse future readers.

3. ID uniqueness relies on wall clock in createQueryInputParams — Both test files generate vertex IDs using System.currentTimeMillis() as a base (e.g. baseTime + (threadId * 100000L) + i). If threads start within the same millisecond, baseTime values can collide across thread invocations in different iterations, causing mergeV to update rather than create, silently breaking the final count assertion. Using a static AtomicLong counter seeded once before the thread pool starts would be more reliable.

Verdict: The two-line change in the diff is correct and should be merged as-is. The observations above are pre-existing technical debt in these test files that could be addressed in a follow-up.

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
Report missing for 3c04b861	✅ ∅

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (3c04b86)	Report Missing	Report Missing	Report Missing
Head commit (fa6b1cf)	140657	91122	64.78%

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#3672)	0	0	∅ (not applicable)

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

Footnotes

1. Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct. ↩

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 65.81%. Comparing base (024b303) to head (7d28087).
⚠️ Report is 6 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3672      +/-   ##
==========================================
- Coverage   65.83%   65.81%   -0.03%     
==========================================
  Files        1550     1550              
  Lines      109700   109733      +33     
  Branches    22878    22891      +13     
==========================================
- Hits        72222    72221       -1     
+ Misses      27799    27790       -9     
- Partials     9679     9722      +43     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[claude]

Code Review

The core fix — replacing hardcoded thread counts with Math.max(2, availableProcessors()) — is correct and well-motivated. The GremlinMergeVStressTest change (single line) is clean. The more substantial rework in GremlinMergeVConcurrentTest has a few issues worth addressing.

---

Issues

1. ExecutionException swallowed without incrementing errorCount — GremlinMergeVConcurrentTest.java:174

} catch (ExecutionException e) {
    System.err.println("Execution exception: " + e.getMessage());
    e.printStackTrace();
    receivedResults++; // errorCount NOT incremented here
}

When a task exhausts all retries and throws, errorCount is not incremented in this catch block. Importer.call() does call errorCount.incrementAndGet() before re-throwing — so for the "all retries exhausted" path there is double-accounting — but any unexpected exception type that reaches here would let the test silently pass. At minimum the catch block should assertThat(false).as("Unexpected ExecutionException: " + e).isTrue() or rethrow.

2. isConcurrentModification inconsistent with GremlinMergeVStressTest — GremlinMergeVConcurrentTest.java:120-126

The new helper only checks "Concurrent modification". The equivalent logic in GremlinMergeVStressTest (lines 126-127) also checks "ConcurrentModificationException". These should be consistent. Consider also checking e instanceof java.util.ConcurrentModificationException to avoid fragile string matching.

3. No backoff between retries — GremlinMergeVConcurrentTest.java:101-114

GremlinMergeVStressTest applies Thread.sleep(10 * attempt) before each retry. The new retry loop in GremlinMergeVConcurrentTest has no sleep, which could cause tight retry spinning and increased contention on the 2-vCPU runners this PR is trying to fix.

4. Unreachable throw loses original exception — GremlinMergeVConcurrentTest.java:116-117

// Should not reach here
throw new RuntimeException("Exhausted retries");

GremlinMergeVStressTest preserves the last exception as cause (line 158). This version loses the original failure context. Use throw new RuntimeException("Exhausted retries", lastException) and track lastException in the loop.

5. Missing final on local variables — GremlinMergeVConcurrentTest.java:95-96

queryInputParams and params are assigned once and never reassigned — they should be final per project style guidelines.

6. System.out.println calls — GremlinMergeVConcurrentTest.java:98, 107, 169, 199

Project guidelines say to remove debug System.out before finishing. These are new additions in this PR.

---

Summary

Severity	Location	Issue
Medium	GremlinMergeVConcurrentTest:174	ExecutionException caught without failing the test
Low	GremlinMergeVConcurrentTest:120-126	isConcurrentModification misses ConcurrentModificationException class name
Low	GremlinMergeVConcurrentTest:101-114	No backoff between retries (contrast with GremlinMergeVStressTest:133-138)
Low	GremlinMergeVConcurrentTest:116-117	Unreachable throw loses original exception cause
Low	GremlinMergeVConcurrentTest:95-96	Missing final on queryInputParams, params
Info	Both files	System.out.println left in (project guideline: remove debug output)

[claude]

PR Review: Fix Gremlin concurrent test threads scaling + PageManagerFlushThread database-closed guard

Summary

This PR addresses two distinct issues:

1. Hardcoded thread counts in Gremlin concurrent/stress tests causing CI failures on 2-vCPU GitHub runners.
2. A PageManagerFlushThread race condition where pages could be flushed after a database was concurrently closed/dropped.

---

1. Test Thread Count Scaling (GremlinMergeVConcurrentTest, GremlinMergeVStressTest)

Positive: The change from hardcoded 8/12 to Math.max(2, Runtime.getRuntime().availableProcessors()) is the correct fix and is consistent with the pattern already used in AbstractGremlinServerIT, RemoteGremlinFactoryIT, GraphAnalyticalView, and QueryEngineManager. This aligns with the codebase's established convention.

Issue — test semantics on 2-vCPU runners:
GremlinMergeVStressTest is labeled a "high concurrency" stress test and was previously using 12 threads. On a 2-vCPU runner it will now run with exactly 2 threads (the floor from Math.max(2, ...)). While the test still exercises concurrency, the stress level is significantly reduced. This may cause the test to pass even if concurrency bugs only manifest at higher thread counts. Consider adding a comment noting that the stress level is hardware-dependent, or gate the stress test differently for CI vs. local environments.

Issue — System.out/System.err in test code:
Both test files contain numerous System.out.println and System.err.println calls. The project's CLAUDE.md guidelines explicitly require removing System.out debug output when work is finished. These are pre-existing, but the new retry logic added by this PR (e.g., line 107 in GremlinMergeVConcurrentTest) also uses System.out. These should be replaced with LogManager.instance().log(...) calls consistent with the rest of the codebase, or removed.

Issue — fragile retry detection via string matching:
GremlinMergeVConcurrentTest uses a private helper isConcurrentModification(Throwable e) that walks the cause chain checking for "Concurrent modification" (case-sensitive substring). GremlinMergeVStressTest inlines similar logic but also checks "ConcurrentModificationException". Both tests target the same scenario but use inconsistent patterns. A more robust approach would check instanceof com.arcadedb.exception.ConcurrentModificationException in the cause chain — this avoids silent breakage if the error message ever changes:

private boolean isConcurrentModification(Throwable e) {
    while (e != null) {
        if (e instanceof com.arcadedb.exception.ConcurrentModificationException)
            return true;
        e = e.getCause();
    }
    return false;
}

Minor — final keyword not used consistently:
The CLAUDE.md guidelines say "use the final keyword when possible on variables and parameters." Several new local variables in the retry loops could be final.

---

2. PageManagerFlushThread — Database-Closed Guard

Positive: The intent is sound. Adding an isOpen() check inside the flush loop prevents attempting to flush pages for a database that has been concurrently dropped or closed.

Issue — no logging on the new break path:
The existing outer check at line 158–159 silently returns without any log message, and the new inner check also silently breaks. If this condition is hit unexpectedly in production (not just during test teardown), it will be completely invisible in logs. Consider a Level.FINE log entry when flushing is aborted mid-batch:

if (!pagesToFlush.database.isOpen()) {
    LogManager.instance().log(this, Level.FINE, "Skipping page flush for closed database '%s'", pagesToFlush.database.getName());
    // clean up pageIndex entries...
    break;
}

Observation — return vs. break asymmetry:
The outer check at line 158–159 uses return while the new inner check uses break. Both paths correctly reach the finally block (Java finally runs in both cases), so this is functionally correct. However, harmonizing to both use break and let finally handle cleanup would improve readability.

Observation — pageIndex cleanup correctness:
The bulk-removal loop using pageIndex.remove(remaining.getPageId(), remaining) (two-argument form) is correct — it only removes the entry if the value still matches the current batch, so any newer version enqueued after this batch won't be incorrectly removed. A brief comment here would help future readers understand this intentional behavior.

---

Summary of Actionable Items

Priority	Item
Should fix	Remove System.out/System.err from new retry logging code (CLAUDE.md requirement)
Should fix	Use instanceof ConcurrentModificationException instead of string-matching for retry detection
Should fix	Unify retry detection logic between GremlinMergeVConcurrentTest and GremlinMergeVStressTest
Consider	Add a log message in PageManagerFlushThread when the new break path is taken
Minor	Apply final keyword to new local variables per CLAUDE.md style guidelines

The core changes are appropriate and solve real problems. The main items are the System.out cleanup (required per project guidelines) and making the retry exception detection more robust.

[robfrank]

Addressed the review feedback in the next commit:

Implemented:

• Added linear backoff (10ms * attempt) between retries, consistent with GremlinMergeVStressTest
• Track lastException and preserve it as cause in the exhausted-retries throw
• Added final to new local variables per project style
• Extended isConcurrentModification to also check "ConcurrentModificationException" string for consistency with the stress test
• Replaced all System.out/System.err with LogManager.instance().log(...) calls
• Added Level.FINE log in PageManagerFlushThread when the database-closed break path is taken

Not implementing instanceof ConcurrentModificationException: The exception crosses the Gremlin wire protocol boundary. On the server side it's com.arcadedb.exception.ConcurrentModificationException, but on the client side it arrives as org.apache.tinkerpop.gremlin.driver.exception.ResponseException with the original error text in the message. The ArcadeDB exception class is not on the Gremlin client classpath, so instanceof would never match. String matching on the message is the correct approach here.

[claude]

Review

The primary goal of this PR — scaling thread counts to availableProcessors() — is correct and consistent with the existing pattern in RemoteGremlinFactoryIT, AbstractGremlinServerIT, and GraphAnalyticalView. The System.out → LogManager migration is also good housekeeping per the project guidelines.

A few issues worth addressing:

---

1. Dead code in the retry loop (GremlinMergeVConcurrentTest.java, lines 125–126)

The code after the for loop is unreachable:

for (int attempt = 1; attempt <= maxRetries; attempt++) {
    try {
        ...
        return ...;
    } catch (final Exception e) {
        lastException = e;
        if (attempt < maxRetries && isConcurrentModification(e)) {
            ...continue;
        }
        errorCount.incrementAndGet();
        throw new RuntimeException(e);  // always throws here on last attempt
    }
}
// This is never reached:
errorCount.incrementAndGet();
throw new RuntimeException("Exhausted retries", lastException);

When attempt == maxRetries, the condition attempt < maxRetries && ... is always false, so we always hit the throw inside the catch. The post-loop lines and the lastException variable are dead code. The InterruptedException handler also falls through to the same dead code. These should be cleaned up to avoid confusion.

---

2. Retry logic masks potential engine bugs

The retry loop absorbs ConcurrentModificationExceptions up to 10 times. If MERGE V is regularly conflicting in concurrent scenarios, that's a signal of a real engine-level issue (the test was presumably catching it before this PR). Silently retrying in a test might hide regressions. Consider at minimum logging a warning-level message (not INFO) when retries are needed, so CI logs surface these events clearly, and consider adding a counter assertion to verify no retries were needed in a healthy run.

---

3. PageManagerFlushThread.java — cleanup iterates already-flushed pages

The cleanup loop inside the isOpen() guard re-iterates all pages in the batch (including ones already flushed and removed from pageIndex in their finally blocks):

for (final MutablePage remaining : pagesToFlush.pages)
    pageIndex.remove(remaining.getPageId(), remaining);  // no-op for already-removed pages

This is correct (idempotent), but wasteful for large batches. It would be cleaner to break to a labelled outer block or restructure to only clean up the remaining unprocessed pages. Not a blocking issue, but worth noting.

Also, the early-exit at line 158 uses return (exits the method) while the mid-loop exit uses break — this inconsistency is minor but return inside the synchronized block would be cleaner than break + falling through.

---

4. Minor: GremlinMergeVConcurrentTest.java — non-final local variables in createQueryInputParams

Not a regression, but the method still uses raw type inference on List and Map without final, inconsistent with the new code's style. Low priority.

---

Summary: The thread-scaling change itself is good and correct. The main issues are the dead code in the retry loop (should be fixed before merge) and the concern about silently swallowing concurrent modification errors in tests. The PageManagerFlushThread.java change is functionally correct.

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
Report missing for 3c04b861	✅ 100.00%

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (3c04b86)	Report Missing	Report Missing	Report Missing
Head commit (127897e)	140661	91156	64.81%

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#3672)	4	4	100.00%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

Footnotes

1. Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct. ↩

[robfrank]

Re: review at #issuecomment-4075480501

Item 1 — "dead code" in retry loop: The post-loop code is reachable. When Thread.sleep inside the retry path throws InterruptedException, the break at line 117 exits the for loop and falls through to the post-loop errorCount.incrementAndGet(); throw new RuntimeException("Exhausted retries", lastException). This correctly handles the interruption case with the preserved lastException.

Item 2 — retry masking bugs: ConcurrentModificationException is expected behavior in ArcadeDB's optimistic concurrency model — the error message itself says "Please retry the operation." The test validates that concurrent mergeV works with retries, as would happen in production. That said, changed the retry log from INFO to WARNING so these events are visible in CI logs.

Items 3, 4: Acknowledged as correct/pre-existing by the reviewer. No changes needed.

[claude]

Replacing test comment with actual review - posted in segments below.

[claude]

How to contribute to ArcadeDB

Contribution License

ArcadeDB is licensed under the Apache License 2.0. By submitting a contribution (pull request, patch, or any other form), you agree that your contribution is licensed under the same terms, as stated in Section 5 of the Apache License 2.0. This means:

• You keep your copyright. You are not transferring ownership of your code to anyone.
• You grant a perpetual license. Your contribution is irrevocably available under Apache 2.0, including copyright and patent grants (Sections 2 and 3).
• No CLA required. We deliberately do not use a Contributor License Agreement. This keeps the copyright distributed among all contributors, which structurally prevents any single entity from changing the project's license. See our Governance for details.

By submitting a contribution, you represent that you have the right to license it under the Apache License 2.0 — i.e., the work is your own, or you have permission from the copyright holder.

Did you find a bug?

• Do not open up a GitHub issue if the bug is a security vulnerability, and instead write to support -at- arcadedb.com.

• Ensure the bug was not already reported by searching on GitHub under Issues.

• If you're unable to find an open issue addressing the problem, open a new one. Be sure to include a title and clear description, as much relevant information as possible, and a code sample or an executable test case demonstrating the expected behavior that is not occurring. Importantly, note the ArcadeDB version, JVM type and version exhibiting the issue.

Did you write a patch that fixes a bug?

• Open a new GitHub pull request with the patch.

• Ensure the PR description clearly describes the problem and solution. Include the relevant issue number if applicable.

Did you fix whitespace, format code, or make a purely cosmetic patch?

Changes that are cosmetic in nature and do not add anything substantial to the stability, functionality, or testability will generally not be accepted.

Do you intend to add a new feature or change an existing one?

• Suggest your change in the ArcadeDB Community and start writing code.

• Do not open an issue on GitHub until you have collected positive feedback about the change. GitHub issues are primarily intended for bug reports and fixes.

Are you adding a new dependency?

When adding new third-party dependencies to ArcadeDB:

1. Check License Compatibility - Ensure the license is compatible with Apache License 2.0

   • ✅ Compatible: Apache 2.0, MIT, BSD (2/3-Clause), EPL, UPL, EDL, public domain
   • ❌ Incompatible: GPL, AGPL, proprietary licenses without explicit permission

2. Update Attribution Files:

   • Add the dependency to ATTRIBUTIONS.md in the appropriate section
   • If the dependency is Apache-licensed and includes a NOTICE file, incorporate required notices into the main NOTICE file
   • If introducing a new license type, add the full license text to the LICENSES/ directory

3. Maintain SPDX Compliance - All new source files must include:

   • SPDX-FileCopyrightText: with copyright holder and years
   • SPDX-License-Identifier: with the SPDX license identifier (e.g., Apache-2.0)

For questions about licensing, please ask in the discussion forum before adding the dependency.

Prepare your environment

Pre-commit

This project uses pre-commit. Every developer should install it locally, please
follow installation instructions for your operative system.

Developer guide

In order to use the latest distribution before the official release, you have to build it from the latest SNAPSHOT version in
the main branch of GitHub. All you need is:

• Java v21 for the runtime or major
• Apache Maven, to build the distribution
• Docker, to build the container images

It's super easy, just follow the following steps:

(1) Download the sources

If you have git installed, execute the following command on a shell or command prompt:

$ git clone git@github.com:ArcadeData/arcadedb.git

With this command above you have just cloned the main branch continaing the latest updates. If you don't have git installed, you
can always download the latest souces
from GitHub as a zip file. After downloaded, unzip the file on
a local folder.

(2) Now build the project using Maven.

Assure you have Apache Maven installed on your computer and execute the following commands:

$ cd arcadedb
$ mvn clean install -DskipTests

The build should take less than a minute.

(3) Use the fresh built distribution

You will find a fresh built distribution under the directory package/target/arcadedb-<version>.dir/arcadedb-<version>/.

For example, if the latest release is the 25.1.1-SNAPSHOT, then the release will be available under the
directory package/target/arcadedb-25.1.1-SNAPSHOT.dir/arcadedb-25.1.1-SNAPSHOT/

Some build targets

Build and run default tests:

$ mvn clean install

To run additional integration test locally use:

$ mvn clean install -P integration

Rebuild Docker images for e2e tests:

$ mvn clean install -DskipTests -Pdocker

Build and run in fail-at-end mode:

$ mvn clean install -fae

Print dependency tree:

$ mvn dependency:tree

[claude]

PageManagerFlushThread.java note: The cleanup loop variable named remaining iterates over ALL pages, not just unprocessed ones. Pages already flushed had pageIndex.remove() called in their finally block. Calling it again is idempotent but the name and comment "Clean up remaining pageIndex entries" are misleading. Also: the new isOpen() in-loop check is redundant given the pre-loop guard — a single pre-loop check is cleaner on the hot path.

[claude]

GremlinMergeVConcurrentTest.java notes: Good changes: replacing System.out/err with LogManager is correct per project conventions; adding final to local variables aligns with the style guide; the retry loop for concurrent-modification errors is pragmatic. Issue: isConcurrentModification reassigns its e parameter preventing it from being declared final. Idiomatic fix: use a for-loop — for (Throwable e = throwable; e != null; e = e.getCause()). Also: ExecutionException increments receivedResults (good, prevents hang) but is swallowed after WARNING log — consider assertThat(errorCount.get()).isZero() for clearer diagnosis. Thread count Math.max(2, availableProcessors()) is acceptable for 2-vCPU CI runners.

[claude]

Minor: GremlinMergeVStressTest change is correct and minimal. Removing the now-unused GlobalConfiguration import is correct. Summary: Approve with minor nits — fix isConcurrentModification to accept a final parameter, and consider adding an explicit errorCount == 0 assertion to the concurrent test.

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
✅ -9.87%	✅ 100.00%

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (3c04b86)	109713	81829	74.58%
Head commit (9ca016d)	140663 (+30950)	91025 (+9196)	64.71% (-9.87%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#3672)	6	6	100.00%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences