Skip to content

fix: correct Bolt protocol version encoding, handshake negotiation and skip limit#3413

Merged
robfrank merged 6 commits intomainfrom
fix/bolt-version
Feb 13, 2026
Merged

fix: correct Bolt protocol version encoding, handshake negotiation and skip limit#3413
robfrank merged 6 commits intomainfrom
fix/bolt-version

Conversation

@robfrank
Copy link
Collaborator

The v4.4 version constant was incorrectly encoded as 0x00000104 (v4.1)
instead of 0x00000404. The version negotiation also didn't handle the
range field used by modern Neo4j 5.x drivers, causing handshake failures.

  The v4.4 version constant was incorrectly encoded as 0x00000104 (v4.1)
  instead of 0x00000404. The version negotiation also didn't handle the
  range field used by modern Neo4j 5.x drivers, causing handshake failures.
@robfrank robfrank added this to the 26.2.1 milestone Feb 13, 2026
@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @robfrank, I'm Gemini Code Assist1! 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 addresses critical issues in the Bolt protocol implementation, primarily focusing on accurate version encoding and robust handshake negotiation. By correcting the Bolt v4.4 version constant and enhancing the negotiation logic to support version ranges, it significantly improves compatibility with modern Neo4j drivers. These changes ensure reliable communication and prevent connection failures, streamlining interactions with the database.

Highlights

  • Bolt Protocol Version Encoding: Corrected the encoding for Bolt protocol version 4.4 from 0x00000104 to the accurate 0x00000404, resolving an issue where the version was incorrectly identified as v4.1.
  • Handshake Negotiation Logic: Updated the Bolt handshake negotiation to properly interpret the 'range' field used by modern Neo4j 5.x drivers, preventing handshake failures by allowing the server to correctly identify compatible minor versions within the client's specified range.
  • Dependency Version Management: Centralized the neo4j-driver.version property in the root pom.xml and updated it to 5.28.10, removing redundant definitions from child modules.

🧠 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
  • bolt/pom.xml
    • Removed the neo4j-driver.version property, centralizing its definition in the parent POM.
  • bolt/src/main/java/com/arcadedb/bolt/BoltNetworkExecutor.java
    • Corrected the SUPPORTED_VERSIONS array to use the proper encoding 0x00000404 for Bolt v4.4.
    • Modified the performHandshake method to correctly parse and utilize the 'range' field during version negotiation, improving compatibility with client-provided version ranges.
  • bolt/src/test/java/com/arcadedb/bolt/BoltChunkedIOTest.java
    • Updated the writeRawInt test case to assert the correct 0x00000404 encoding for Bolt v4.4.
  • bolt/src/test/java/com/arcadedb/bolt/BoltProtocolIT.java
    • Refactored a multi-line string for a session.run command into a Java text block for improved readability.
  • e2e/pom.xml
    • Removed the neo4j-driver.version property, centralizing its definition in the parent POM.
  • pom.xml
    • Updated the neo4j-driver.version property to 5.28.10.
Activity
  • No specific activity (comments, reviews, progress) has been recorded for 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.

@mergify
Copy link
Contributor

mergify bot commented Feb 13, 2026

🧪 CI Insights

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

🟢 All jobs passed!

But CI Insights is watching 👀

@claude
Copy link

claude bot commented Feb 13, 2026

Code Review - PR #3413: Fix Bolt Protocol Version Encoding and Handshake Negotiation

Summary

This PR addresses a critical bug in Bolt protocol version negotiation where v4.4 was incorrectly encoded as 0x00000104 (representing v4.1) instead of 0x00000404. Additionally, it implements proper range-based version negotiation to support modern Neo4j 5.x drivers.


Positive Aspects ✅

1. Critical Bug Fix

  • Correct encoding: Changed 0x000001040x00000404 for Bolt v4.4
  • The encoding format [unused(8)][range(8)][minor(8)][major(8)] is now properly documented inline
  • This fixes handshake failures with Neo4j 5.x drivers

2. Range Support Implementation

  • Properly implements the range field for version negotiation (lines 209-233 in BoltNetworkExecutor.java)
  • Allows clients to specify a range of compatible minor versions
  • Follows Bolt protocol specification for backward compatibility

3. Improved Code Quality

  • Added comprehensive inline comments explaining the bit layout
  • Test updated consistently (BoltChunkedIOTest.java)
  • Code formatting improvement using text blocks (BoltProtocolIT.java:599-605)

4. Dependency Management

  • Consolidated neo4j-driver.version to parent pom.xml (5.28.10)
  • Removed redundant property declarations from child modules
  • Cleaner dependency management

Issues and Concerns ⚠️

1. Potential Logic Error in Range Calculation 🔴 HIGH PRIORITY

Location: BoltNetworkExecutor.java:226

The version matching condition appears incorrect:

if (clientMajor == serverMajor && serverMinor <= clientMinor && serverMinor >= clientMinor - clientRange)

Issue: This checks if serverMinor falls within the client's range, but according to Bolt protocol specification, we should check if the client supports our server version.

Expected behavior: If client requests v4.4 with range=2 (supporting v4.2-v4.4), and server supports v4.4, this should match.

Let me trace through an example:

  • Client sends: 0x00020404 (major=4, minor=4, range=2 → supports 4.2-4.4)
  • Server supports: 0x00000404 (major=4, minor=4)
  • Current logic: 4 == 4 && 4 <= 4 && 4 >= 4-2true && true && trueThis works

However, consider this scenario:

  • Client sends: 0x00020404 (supports 4.2-4.4)
  • Server supports: 0x00000403 (v4.3)
  • Current logic: 4 == 4 && 3 <= 4 && 3 >= 2true && true && trueThis also works

Actually, upon further analysis, the logic seems correct. The condition properly checks if the server's minor version falls within the client's acceptable range.

Recommendation: Add unit tests to validate this logic with various scenarios.

2. Missing Unit Tests for Version Negotiation 🟡 MEDIUM PRIORITY

Issue: There are no dedicated unit tests for the performHandshake() method or version negotiation logic.

What's needed:

  • Test cases for exact version matches
  • Test cases for range-based matching
  • Test cases with multiple client versions in preference order
  • Test cases where no version matches (should return 0)
  • Edge cases: range=0, range=255, all zeros, etc.

Example test scenarios:

// Scenario 1: Client with range supports server version
clientVersions = [0x00020404]; // supports 4.2-4.4
serverVersions = [0x00000403]; // v4.3
expected = 0x00000403; // Should match

// Scenario 2: Server version outside client range
clientVersions = [0x00010405]; // supports 4.4-4.5 (range=1)
serverVersions = [0x00000402]; // v4.2
expected = 0; // No match

// Scenario 3: Multiple client versions, pick best
clientVersions = [0x00000005, 0x00000404]; // v5.0, v4.4
serverVersions = [0x00000404, 0x00000004]; // v4.4, v4.0
expected = 0x00000404; // Should match v4.4

3. Zero-Check Position 🟢 LOW PRIORITY

Location: BoltNetworkExecutor.java:215-216

if (clientVersion == 0)
    continue;

Observation: This check is good, but according to Bolt spec, zeros indicate "no more versions". Once a zero is encountered, subsequent entries should also be zero.

Recommendation: Consider breaking instead of continuing, or add a comment explaining why we continue checking remaining slots.

4. Documentation Gap 🟢 LOW PRIORITY

The inline comment on line 72 uses Unicode em-dash which might not render correctly in all editors:

// Encoding: [unused(8)][range(8)][minor(8)][major(8)] — major = value & 0xFF

Recommendation: Use standard ASCII dash or add line break for better readability.


Security Considerations 🔒

No security issues identified

  • No user input validation issues
  • No injection vulnerabilities
  • Proper bounds checking on bit operations
  • Range values are properly masked to 8 bits

Performance Considerations ⚡

Performance impact is minimal

  • Handshake only occurs once per connection
  • Bit operations are fast
  • No additional allocations introduced
  • Loop complexity remains O(n×m) where n=4 client versions, m=3 server versions

Test Coverage 📊

Current state:

  • ✅ Basic I/O test updated (BoltChunkedIOTest.writeRawInt)
  • ✅ Integration tests exist (BoltProtocolIT)
  • Missing: Dedicated unit tests for version negotiation logic

Verification needed:
Per CLAUDE.md guidelines, all server-side code changes require test coverage. The version negotiation logic should have comprehensive unit tests.


Recommendations 📝

Must Have (Before Merge):

  1. Add unit tests for performHandshake() method covering:
    • Exact version matches
    • Range-based matching scenarios
    • Edge cases (all zeros, no match, etc.)
    • Multiple client version preferences

Should Have:

  1. Run full test suite on bolt module to ensure no regressions
  2. Test with actual Neo4j 5.x driver to confirm handshake succeeds

Nice to Have:

  1. Add logging for range values in debug mode
  2. Consider adding assertion for "zeros after first zero" in client versions

Code Style Compliance ✅

Adheres to project conventions:

  • ✅ Uses final keyword appropriately
  • ✅ Single-statement if blocks without braces (consistent with existing code)
  • ✅ Proper inline comments
  • ✅ No unnecessary fully qualified names
  • ✅ No System.out.println left behind

Conclusion

This is a critical bug fix that resolves compatibility issues with modern Neo4j drivers. The core changes are sound, but the PR would benefit from comprehensive unit tests for the version negotiation logic before merging.

Recommendation: ✅ Approve with changes - merge after adding unit tests for the negotiation logic.

Priority: The bug fix itself is correct and urgently needed. Consider merging with a follow-up PR for comprehensive tests if time is critical.


Tested: Manual code review and logic verification
Verification method needed: Integration tests with Neo4j 5.x driver, unit tests for edge cases

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request correctly fixes an issue with Bolt protocol version encoding and handshake negotiation. The v4.4 constant is now correctly encoded, and the negotiation logic properly handles version ranges from modern Neo4j drivers. The dependency for neo4j-driver has also been centralized and updated. My review includes one suggestion to improve code readability by encapsulating the version parsing logic into helper methods.

Comment on lines +218 to +224
final int clientMajor = clientVersion & 0xFF;
final int clientMinor = (clientVersion >> 8) & 0xFF;
final int clientRange = (clientVersion >> 16) & 0xFF;

for (final int supportedVersion : SUPPORTED_VERSIONS) {
// Check major version match (upper 16 bits for BOLT 4.x)
if (clientVersion == supportedVersion ||
(clientVersion >> 8) == (supportedVersion >> 8)) {
final int serverMajor = supportedVersion & 0xFF;
final int serverMinor = (supportedVersion >> 8) & 0xFF;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

To improve readability and encapsulate the logic for parsing Bolt protocol versions, consider extracting the bitwise operations into private helper methods. This makes the version negotiation logic easier to understand and maintain.

For example, you could add the following static helper methods to the BoltNetworkExecutor class:

private static int getMajorVersion(int version) {
    return version & 0xFF;
}

private static int getMinorVersion(int version) {
    return (version >> 8) & 0xFF;
}

private static int getVersionRange(int version) {
    return (version >> 16) & 0xFF;
}

Then, you can use these methods to simplify the code in the loop.

Suggested change
final int clientMajor = clientVersion & 0xFF;
final int clientMinor = (clientVersion >> 8) & 0xFF;
final int clientRange = (clientVersion >> 16) & 0xFF;
for (final int supportedVersion : SUPPORTED_VERSIONS) {
// Check major version match (upper 16 bits for BOLT 4.x)
if (clientVersion == supportedVersion ||
(clientVersion >> 8) == (supportedVersion >> 8)) {
final int serverMajor = supportedVersion & 0xFF;
final int serverMinor = (supportedVersion >> 8) & 0xFF;
final int clientMajor = getMajorVersion(clientVersion);
final int clientMinor = getMinorVersion(clientVersion);
final int clientRange = getVersionRange(clientVersion);
for (final int supportedVersion : SUPPORTED_VERSIONS) {
final int serverMajor = getMajorVersion(supportedVersion);
final int serverMinor = getMinorVersion(supportedVersion);

@claude
Copy link

claude bot commented Feb 13, 2026

Pull Request Review

This PR fixes a critical bug in the Bolt protocol version negotiation. The changes are well-implemented and thoroughly tested.


Strengths

1. Correct Bug Fix

  • Fixed v4.4 encoding: Changed from 0x00000104 (incorrectly v4.1) to 0x00000404 (correctly v4.4)
  • Root cause: The encoding format is [unused(8)][range(8)][minor(8)][major(8)], so v4.4 should be (4 << 8) | 4 = 0x404
  • This fix resolves handshake failures with modern Neo4j 5.x drivers

2. Excellent Test Coverage

The new BoltVersionNegotiationTest.java is exemplary:

  • 197 lines of comprehensive unit tests
  • Tests helper methods (getMajorVersion, getMinorVersion, getVersionRange)
  • Tests negotiation algorithm with 13 different scenarios including exact matches, range-based matching, edge cases, and real-world scenarios
  • Clear comments explaining each test case
  • Follows project conventions (AssertJ syntax, proper naming)

3. Proper Range Support Implementation

The negotiation logic now correctly handles the range field, allowing clients to specify version ranges (e.g., "I support v4.2 through v4.4")

4. Good Code Hygiene

  • Added inline documentation explaining Bolt version encoding
  • Made helper methods static and package-private for testability
  • Removed duplicate neo4j-driver.version property definitions (DRY principle)
  • Centralized version property in root POM

Security Considerations

No security concerns. The changes:

  • Handle integer operations safely (no overflow issues)
  • Properly validate version negotiation
  • Don't expose sensitive data
  • Fail safely when no compatible version is found

Performance Considerations

Excellent performance characteristics:

  • Simple nested loops with early termination
  • Maximum 4 client versions x 3 server versions = 12 iterations worst case
  • No allocations in hot path (only during handshake)
  • Integer bitwise operations are extremely fast

Testing Recommendations

Please verify integration tests pass, especially BoltProtocolIT which tests end-to-end handshakes with real Neo4j drivers.


Final Verdict

Recommendation: APPROVE with minor testing verification

This is a high-quality fix that:

  1. Correctly resolves the version encoding bug
  2. Implements proper range support for modern clients
  3. Includes exceptional test coverage
  4. Follows project conventions
  5. Has no security or performance concerns

Before Merging:

  1. Verify compilation: mvn clean install -pl bolt -DskipTests
  2. Run unit tests: mvn test -pl bolt
  3. Run integration tests: mvn test -pl bolt -DskipITs=false

Great work on this fix! The bug was subtle (incorrect hex encoding) but would have caused real-world connection failures. The comprehensive test suite ensures this won't regress.
EOF < /dev/null

@github-actions
Copy link
Contributor

📜 License Compliance Check

✅ License check passed. See artifacts for full report.

License Summary (first 50 lines)

Lists of 393 third-party dependencies.
     (Apache License 2.0) LZ4 Java Compression (at.yawk.lz4:lz4-java:1.10.3 - https://github.com/yawkat/lz4-java)
     (EPL 2.0) (GNU Lesser General Public License) Logback Classic Module (ch.qos.logback:logback-classic:1.5.28 - http://logback.qos.ch/logback-classic)
     (EPL 2.0) (GNU Lesser General Public License) Logback Core Module (ch.qos.logback:logback-core:1.5.28 - http://logback.qos.ch/logback-core)
     (Apache 2) ArcadeDB BOLT Protocol (com.arcadedb:arcadedb-bolt:26.2.1-SNAPSHOT - https://arcadedata.com/arcadedb-bolt/)
     (Apache 2) ArcadeDB Console (com.arcadedb:arcadedb-console:26.2.1-SNAPSHOT - https://arcadedata.com/arcadedb-console/)
     (Apache 2) ArcadeDB Engine (com.arcadedb:arcadedb-engine:26.2.1-SNAPSHOT - https://arcadedata.com/arcadedb-engine/)
     (Apache 2) ArcadeDB GraphQL (com.arcadedb:arcadedb-graphql:26.2.1-SNAPSHOT - https://arcadedata.com/arcadedb-graphql/)
     (Apache 2) ArcadeDB Gremlin (com.arcadedb:arcadedb-gremlin:26.2.1-SNAPSHOT - https://arcadedata.com/arcadedb-gremlin/)
     (Apache 2) ArcadeDB gRPC Stubs (com.arcadedb:arcadedb-grpc:26.2.1-SNAPSHOT - https://arcadedata.com/arcadedb-grpc/)
     (Apache 2) ArcadeDB gRPC Client (com.arcadedb:arcadedb-grpc-client:26.2.1-SNAPSHOT - https://arcadedata.com/arcadedb-grpc-client/)
     (Apache 2) ArcadeDB gRpcW (com.arcadedb:arcadedb-grpcw:26.2.1-SNAPSHOT - https://arcadedata.com/arcadedb-grpcw/)
     (Apache 2) ArcadeDB Integration (com.arcadedb:arcadedb-integration:26.2.1-SNAPSHOT - https://arcadedata.com/arcadedb-integration/)
     (Apache 2) ArcadeDB Metrics (com.arcadedb:arcadedb-metrics:26.2.1-SNAPSHOT - https://arcadedata.com/arcadedb-metrics/)
     (Apache 2) ArcadeDB MongoDB Wire Protocol (com.arcadedb:arcadedb-mongodbw:26.2.1-SNAPSHOT - https://arcadedata.com/arcadedb-mongodbw/)
     (Apache 2) ArcadeDB Network (com.arcadedb:arcadedb-network:26.2.1-SNAPSHOT - https://arcadedata.com/arcadedb-network/)
     (Apache 2) ArcadeDB PostgresW (com.arcadedb:arcadedb-postgresw:26.2.1-SNAPSHOT - https://arcadedata.com/arcadedb-postgresw/)
     (Apache 2) ArcadeDB RedisW (com.arcadedb:arcadedb-redisw:26.2.1-SNAPSHOT - https://arcadedata.com/arcadedb-redisw/)
     (Apache 2) ArcadeDB Server (com.arcadedb:arcadedb-server:26.2.1-SNAPSHOT - https://arcadedata.com/arcadedb-server/)
     (Apache 2) ArcadeDB Studio (com.arcadedb:arcadedb-studio:26.2.1-SNAPSHOT - https://arcadedata.com/arcadedb-studio/)
     (Apache 2) ArcadeDB Test Utils (com.arcadedb:arcadedb-test-utils:26.2.1-SNAPSHOT - https://arcadedata.com/arcadedb-test-utils/)
     (Apache License 2.0) HPPC Collections (com.carrotsearch:hppc:0.7.1 - http://labs.carrotsearch.com/hppc.html/hppc)
     (Apache License 2.0) Metrics Core (com.codahale.metrics:metrics-core:3.0.2 - http://metrics.codahale.com/metrics-core/)
     (The Apache License, Version 2.0) com.conversantmedia:disruptor (com.conversantmedia:disruptor:1.2.21 - https://github.com/conversant/disruptor)
     (Apache License 2.0) Jackson-annotations (com.fasterxml.jackson.core:jackson-annotations:2.19.2 - https://github.com/FasterXML/jackson)
     (Apache License 2.0) Jackson-annotations (com.fasterxml.jackson.core:jackson-annotations:2.20 - https://github.com/FasterXML/jackson)
     (Apache License 2.0) Jackson-annotations (com.fasterxml.jackson.core:jackson-annotations:2.21 - https://github.com/FasterXML/jackson)
     (Apache License 2.0) Jackson-core (com.fasterxml.jackson.core:jackson-core:2.19.2 - https://github.com/FasterXML/jackson-core)
     (Apache License 2.0) Jackson-core (com.fasterxml.jackson.core:jackson-core:2.21.0 - https://github.com/FasterXML/jackson-core)
     (Apache License 2.0) jackson-databind (com.fasterxml.jackson.core:jackson-databind:2.19.2 - https://github.com/FasterXML/jackson)
     (Apache License 2.0) jackson-databind (com.fasterxml.jackson.core:jackson-databind:2.21.0 - https://github.com/FasterXML/jackson)
     (Apache License 2.0) Jackson-dataformat-YAML (com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:2.19.2 - https://github.com/FasterXML/jackson-dataformats-text)
     (Apache License 2.0) Jackson datatype: JSR310 (com.fasterxml.jackson.datatype:jackson-datatype-jsr310:2.19.2 - https://github.com/FasterXML/jackson-modules-java8/jackson-datatype-jsr310)
     (Apache License 2.0) Caffeine cache (com.github.ben-manes.caffeine:caffeine:2.3.1 - https://github.com/ben-manes/caffeine)
     (Apache License 2.0) docker-java-api (com.github.docker-java:docker-java-api:3.7.0 - https://github.com/docker-java/docker-java)
     (Apache License 2.0) docker-java-transport (com.github.docker-java:docker-java-transport:3.7.0 - https://github.com/docker-java/docker-java)
     (Apache License 2.0) docker-java-transport-zerodep (com.github.docker-java:docker-java-transport-zerodep:3.7.0 - https://github.com/docker-java/docker-java)
     (Apache Software License, version 2.0) (Lesser General Public License, version 3 or greater) btf (com.github.java-json-tools:btf:1.3 - https://github.com/java-json-tools/btf)
     (Apache Software License, version 2.0) (Lesser General Public License, version 3 or greater) jackson-coreutils (com.github.java-json-tools:jackson-coreutils:2.0 - https://github.com/java-json-tools/jackson-coreutils)
     (Apache Software License, version 2.0) (Lesser General Public License, version 3 or greater) jackson-coreutils-equivalence (com.github.java-json-tools:jackson-coreutils-equivalence:1.0 - https://github.com/java-json-tools/jackson-coreutils)
     (Apache Software License, version 2.0) (Lesser General Public License, version 3 or greater) json-patch (com.github.java-json-tools:json-patch:1.13 - https://github.com/java-json-tools/json-patch)
     (Apache Software License, version 2.0) (Lesser General Public License, version 3 or greater) json-schema-core (com.github.java-json-tools:json-schema-core:1.2.14 - https://github.com/java-json-tools/json-schema-core)
     (Apache Software License, version 2.0) (Lesser General Public License, version 3 or greater) json-schema-validator (com.github.java-json-tools:json-schema-validator:2.2.14 - https://github.com/java-json-tools/json-schema-validator)
     (Apache Software License, version 2.0) (Lesser General Public License, version 3 or greater) msg-simple (com.github.java-json-tools:msg-simple:1.2 - https://github.com/java-json-tools/msg-simple)
     (Apache Software License, version 2.0) (Lesser General Public License, version 3 or greater) uri-template (com.github.java-json-tools:uri-template:0.10 - https://github.com/java-json-tools/uri-template)
     (Apache License 2.0) (GNU Lesser General Public License) javaparser-core (com.github.javaparser:javaparser-core:3.26.3 - https://github.com/javaparser/javaparser-core)
     (Apache License 2.0) JCIP Annotations under Apache License (com.github.stephenc.jcip:jcip-annotations:1.0-1 - http://stephenc.github.com/jcip-annotations)
     (Apache License 2.0) Google Android Annotations Library (com.google.android:annotations:4.1.1.4 - http://source.android.com/)
     (BSD 3-Clause) API Common (com.google.api:api-common:2.53.0 - https://github.com/googleapis/sdk-platform-java)

@claude
Copy link

claude bot commented Feb 13, 2026

Code Review: Bolt Protocol Version Encoding and Handshake Negotiation

Thank you for this fix! This PR addresses a critical bug in the Bolt protocol version negotiation. Here's my detailed review:

✅ Strengths

  1. Critical Bug Fix: The correction from 0x00000104 (v4.1) to 0x00000404 (v4.4) is correct and essential. The original encoding was definitely wrong.

  2. Excellent Test Coverage: The new BoltVersionNegotiationTest class is comprehensive and well-structured:

    • Unit tests for helper methods (getMajorVersion, getMinorVersion, getVersionRange)
    • Extensive negotiation scenarios (exact matches, range matches, edge cases)
    • Real-world simulation tests (Neo4j 4.x and 5.x driver handshakes)
    • Edge case handling (padding, zero entries)
  3. Proper Range Support: The implementation correctly handles the range field for modern Neo4j 5.x drivers, which was previously missing.

  4. Clear Documentation: The inline comments clearly explain the version encoding format [unused(8)][range(8)][minor(8)][major(8)].

  5. Dependency Management: Moving neo4j-driver.version to the parent POM centralizes version management, which is good practice.

⚠️ Issues Found

1. Debug Code Left In (MUST FIX)

File: bolt/src/test/java/com/arcadedb/bolt/BoltProtocolIT.java:583

System.out.println("result = " + result);

Per CLAUDE.md guidelines:

"remove any System.out you used for debug when you have finished"

Action Required: Remove this debug statement before merging.

2. Method Visibility (Minor)

The helper methods are currently package-private (static):

static int getMajorVersion(final int version)
static int getMinorVersion(final int version)
static int getVersionRange(final int version)

These are only used in tests and within the class itself. Consider:

  • Making them private static if they're only for internal use
  • OR keeping them package-private for testing (current approach is acceptable)

The current approach is fine since tests need access, but adding a comment explaining this would be helpful.

3. Test Method Naming Convention (Very Minor)

The test class uses method names without the test prefix (e.g., exactVersionMatch()), which is fine for JUnit 5, but other test files in the project may use testXxx() naming. Consistency across the codebase would be ideal, though this is minor.

🔍 Code Quality Observations

  1. Algorithm Correctness: The negotiation algorithm correctly implements:

    • Client preference ordering (first match wins)
    • Range-based version matching
    • Proper handling of zero padding
  2. Performance: The nested loop approach is fine given the small fixed size (4 client versions × 3 supported versions).

  3. Edge Cases: Well handled:

    • Zero padding detection with early break
    • No match returns 0
    • Range boundary checks
  4. Code Style: Adheres to project conventions:

    • Proper use of final keyword
    • Single-statement if blocks without braces (consistent with project style)
    • Proper indentation and formatting

🔐 Security & Performance

  • No Security Issues: The change doesn't introduce security vulnerabilities
  • No Performance Impact: The negotiation happens once per connection during handshake
  • Backward Compatibility: Maintains support for v4.0 and v3.0, ensuring existing clients continue to work

📋 Suggestions

  1. Add Integration Test: While unit tests are excellent, consider adding an integration test that:

    • Actually connects with a real Neo4j 5.x driver
    • Verifies the handshake succeeds
    • Confirms queries work after negotiation
  2. Version Range Documentation: Consider adding a comment explaining why the range check is serverMinor <= clientMinor && serverMinor >= clientMinor - clientRange for developers unfamiliar with the Bolt spec.

  3. Test Isolation: The transactionIsolation test changes look good (better structure with explicit rollback/commit testing), but are unrelated to this PR. Consider moving unrelated test improvements to a separate PR for clarity.

✅ Approval Recommendation

This PR should be approved after fixing the debug statement.

The core fix is critical and correct. The test coverage is exemplary. Once the System.out.println is removed, this is ready to merge.

Action Items

  • Remove System.out.println from BoltProtocolIT.java:583
  • Verify tests pass (especially BoltVersionNegotiationTest)
  • Consider adding a comment explaining why helper methods are package-private

Overall Assessment: High-quality fix with excellent test coverage. One small cleanup needed before merge.

@claude
Copy link

claude bot commented Feb 13, 2026

Pull Request Review

This PR fixes two critical issues in the Bolt protocol implementation and addresses a performance optimization bug in Cypher query execution. Overall, this is a well-structured, high-quality fix with excellent test coverage.


✅ Strengths

1. Correct Bug Fixes

  • Bolt v4.4 encoding: Fixed the critical typo where v4.4 was encoded as 0x00000104 (which is actually v4.1) instead of the correct 0x00000404. This would have caused handshake failures with modern drivers.
  • Range negotiation: Properly implemented the Bolt protocol range field used by Neo4j 5.x drivers, allowing backward compatibility.
  • ORDER BY + SKIP/LIMIT optimization: Fixed the top-K optimization to account for SKIP, preventing incorrect results when using pagination with sorting.

2. Excellent Test Coverage

  • BoltVersionNegotiationTest: 197 lines of comprehensive unit tests covering:
    • Version encoding/decoding helpers
    • Exact version matching
    • Range-based negotiation
    • Edge cases (zero padding, unsupported versions)
    • Real-world Neo4j 4.x and 5.x driver handshakes
  • OpenCypherOrderBySkipLimitTest: New test reproducing the Bolt scenario with 10 nodes
  • Improved BoltProtocolIT: Better transaction isolation test that validates both rollback and commit behavior

3. Code Quality

  • Clear inline documentation explaining the Bolt version encoding format
  • Helper methods (getMajorVersion, getMinorVersion, getVersionRange) with package visibility for testability
  • Follows existing code style (no curly braces for single-line if statements)
  • Uses final keyword appropriately

4. Dependency Management

  • Properly centralized neo4j-driver.version in parent POM (moved from bolt and e2e modules)
  • Updated to Neo4j driver 5.28.10 (from 5.27.0)

🔍 Code Analysis

Bolt Version Negotiation Logic

The negotiation algorithm in BoltNetworkExecutor.java:209-232 correctly implements the Bolt protocol spec:

if (clientMajor == serverMajor && serverMinor <= clientMinor && serverMinor >= clientMinor - clientRange)

This logic ensures the server version falls within the client's supported range: [clientMinor - clientRange, clientMinor].

Correctness verified by test case: rangeMatchClientSupports4_2through4_4 - client with range=2 at v4.4 supports 4.2-4.4, and server's v4.4 correctly matches.

Cypher Top-K Optimization Fix

The fix in CypherExecutionPlan.java addresses a subtle bug where OrderByStep was given LIMIT for top-K optimization, but when SKIP is applied afterward, not enough rows survive. The solution correctly passes LIMIT + SKIP to the sorter:

final Integer topKVal = limitVal != null ? limitVal + (skipVal != null ? skipVal : 0) : null;

This ensures that after skipping N rows, there are still M rows remaining for the limit.


🐛 Potential Issues

1. Minor: Code Duplication in CypherExecutionPlan

The top-K calculation logic is duplicated in 5 locations within CypherExecutionPlan.java:

  • Lines 611-617
  • Lines 674-680
  • Lines 1063-1069
  • Lines 1153-1159
  • Lines 1899-1905

Recommendation: Extract this to a helper method to reduce duplication and improve maintainability:

private Integer calculateTopK(final Expression skipExpr, final Expression limitExpr, 
                              final Result context) {
  final Integer limitVal = limitExpr != null ? 
      new ExpressionEvaluator(functionFactory).evaluateSkipLimit(limitExpr, 
          new ResultInternal(), context) : null;
  final Integer skipVal = skipExpr != null ?
      new ExpressionEvaluator(functionFactory).evaluateSkipLimit(skipExpr,
          new ResultInternal(), context) : null;
  return limitVal != null ? limitVal + (skipVal != null ? skipVal : 0) : null;
}

However, this is a minor issue and can be addressed in a future refactoring PR.

2. Minor: Test Method Visibility

The helper methods in BoltNetworkExecutor (getMajorVersion, etc.) are package-private for testability. While this works, consider making them public static if they might be useful elsewhere, or keeping them private and testing through the public API only. Package-private is acceptable but not ideal.


🔒 Security Considerations

No security issues identified. The changes are protocol-level fixes that don't introduce:

  • SQL/Cypher injection risks
  • Authentication/authorization bypasses
  • Information disclosure
  • Resource exhaustion vulnerabilities

⚡ Performance Considerations

Positive Impact

The Cypher fix improves correctness without degrading performance. The top-K optimization still applies correctly - it just requests the right number of rows now.

No Regression Concerns

  • Version negotiation happens once per connection (negligible overhead)
  • Helper methods are simple bit operations (no performance impact)
  • The repeated top-K calculations in CypherExecutionPlan happen at query planning time (not execution), so duplication doesn't affect runtime performance

📋 Test Coverage Assessment

Excellent coverage:

  • ✅ Unit tests for version encoding helpers
  • ✅ Unit tests for negotiation algorithm (14 test cases)
  • ✅ Integration test for Bolt protocol SKIP+LIMIT
  • ✅ Cypher engine test for ORDER BY+SKIP+LIMIT
  • ✅ Improved transaction isolation test

Suggested additional testing (can be future work):

  • Integration test with actual Neo4j 5.x driver to verify real-world compatibility
  • Performance benchmark for large result sets with ORDER BY+SKIP+LIMIT

📝 Documentation & Comments

Well-documented:

  • Clear commit message explaining both fixes
  • Inline comments explaining Bolt encoding format
  • Test method names are descriptive
  • Comments in test cases explain expected behavior

Minor suggestion: Consider adding a brief comment in CypherExecutionPlan.java explaining why top-K needs to account for SKIP:

// Top-K must account for SKIP so enough rows survive after skipping.
// Example: SKIP 5 LIMIT 5 needs to fetch at least 10 rows from the sorter.

✅ Adherence to CLAUDE.md Guidelines

  • ✅ Uses assertThat().isEqualTo() syntax for assertions
  • ✅ Follows existing code style (single-line if statements without braces)
  • ✅ Uses final keyword appropriately
  • ✅ No System.out debug statements
  • ✅ Properly imports classes (no fully qualified names)
  • ✅ Apache 2.0 license headers present
  • ✅ Dependency version centralized in parent POM
  • ✅ No new external dependencies added

🎯 Final Recommendation

APPROVE with minor suggestions for future improvement.

This PR:

  1. ✅ Fixes critical bugs that would prevent Neo4j 5.x driver compatibility
  2. ✅ Fixes correctness issue with Cypher pagination
  3. ✅ Has comprehensive test coverage
  4. ✅ Follows project conventions
  5. ✅ No security or performance regressions

The minor code duplication in CypherExecutionPlan.java can be addressed in a future refactoring PR if desired, but doesn't block this critical bug fix.

Great work! 🎉

@claude
Copy link

claude bot commented Feb 13, 2026

Pull Request Review: Fix Bolt Protocol Version Encoding and Handshake Negotiation

Summary

This PR fixes a critical bug in the Bolt protocol implementation where v4.4 was incorrectly encoded as 0x00000104 (v4.1) instead of 0x00000404, and adds proper support for the range field used by modern Neo4j 5.x drivers. The PR also includes an important fix for OpenCypher's ORDER BY + SKIP + LIMIT optimization.


✅ Strengths

1. Excellent Bug Fix

The core fix correctly addresses the version encoding issue:

  • Before: 0x00000104 incorrectly represented v4.1
  • After: 0x00000404 correctly represents v4.4
  • The encoding format [unused(8)][range(8)][minor(8)][major(8)] is now properly documented

2. Comprehensive Test Coverage

The new BoltVersionNegotiationTest.java is exemplary:

  • 15+ test cases covering edge cases (exact matches, range negotiation, padding, fallback scenarios)
  • Tests real-world scenarios (Neo4j 5.x and 4.x driver handshakes)
  • Clear, well-documented test methods
  • Follows the project's preferred assertion style: assertThat().isEqualTo()

3. Proper Range Field Support

The negotiation logic now correctly implements Bolt's range field:

if (clientMajor == serverMajor && serverMinor <= clientMinor && serverMinor >= clientMinor - clientRange)

This ensures compatibility with modern Neo4j 5.x drivers.

4. Code Quality

  • Clean separation of concerns (helper methods for version extraction)
  • Good inline comments explaining the negotiation logic
  • Consistent with project coding standards
  • Methods appropriately scoped as package-private static for testing

5. OpenCypher Fix is Critical

The Top-K optimization fix in CypherExecutionPlan.java solves a correctness issue:

  • Before: OrderByStep received only LIMIT value, causing incorrect results when SKIP > 0
  • After: OrderByStep receives SKIP + LIMIT to retain enough rows before skipping
  • New test orderBySkipLimitWithManyNodes() validates the fix

⚠️ Issues & Concerns

1. Critical: Maven Surefire Configuration Change

Location: pom.xml:212-214

<excludes>
    <exclude>**/*IT.java</exclude>
</excludes>

Issue: This excludes all integration tests from the default mvn test run. According to CLAUDE.md:

Run all the connected tests could be affected by the change to ensure nothing is broken

Why this is problematic:

  • The existing skipITs property already controls integration tests
  • This hardcoded exclusion bypasses that mechanism
  • Developers may unknowingly skip integration tests
  • CI pipelines may need adjustment

Recommendation: Remove this change unless there's a compelling reason (if so, document it in the commit message).


2. Potential Performance Impact

Location: CypherExecutionPlan.java (multiple locations)

The Top-K optimization now uses topKVal = limitVal + skipVal, which means:

  • More rows retained in memory during sorting
  • For ORDER BY ... SKIP 1000000 LIMIT 10, the OrderByStep will keep 1,000,010 rows instead of 10

Recommendation: Consider adding a reasonable upper bound or documenting this trade-off. For very large SKIP values, this could cause memory pressure.


3. Missing Edge Case: Integer Overflow

Location: CypherExecutionPlan.java:615

final Integer topKVal = limitVal != null ? limitVal + (skipVal != null ? skipVal : 0) : null;

Issue: If limitVal + skipVal exceeds Integer.MAX_VALUE, this will silently overflow.

Recommendation:

final Integer topKVal = limitVal != null 
    ? Math.addExact(limitVal, (skipVal != null ? skipVal : 0)) 
    : null;

Or add explicit bounds checking with a meaningful error message.


4. Neo4j Driver Version Centralization

Location: bolt/pom.xml, e2e/pom.xml, pom.xml

Good: Moved neo4j-driver.version to the parent POM for centralization.

Concern: The PR description doesn't mention this change. Was this intentional or accidental? Also, the version was bumped from 5.27.0 to 5.28.10 without explanation.

Recommendation: Mention in the PR description if the version bump is related to the fix (e.g., testing with newer drivers).


5. Minor: Test Isolation Concern

Location: BoltProtocolIT.java:597-605

The transactionIsolation() test was rewritten to use a single session. While simpler, the original test verified isolation between sessions, which is a stronger guarantee.

Original intent: Session 1 creates uncommitted data → Session 2 shouldn't see it
New behavior: Single session rollback → same session shouldn't see rolled-back data

Recommendation: Consider keeping both tests (rename the new one to transactionRollback) to maintain the cross-session isolation test coverage.


🔍 Security & Safety

✅ No Security Concerns

  • Input validation: Version negotiation safely handles malformed client proposals (zero padding, out-of-range values)
  • No SQL injection or unsafe deserialization risks introduced
  • No new dependencies added

📊 Test Coverage Assessment

Bolt Protocol Changes

  • ✅ Unit tests for version encoding helpers
  • ✅ Comprehensive negotiation scenarios
  • ✅ Integration test validates real Neo4j driver compatibility
  • ✅ Edge cases covered (padding, range matching, fallback)

OpenCypher Changes

  • ✅ New test orderBySkipLimitWithManyNodes() validates the fix
  • ⚠️ Could benefit from testing larger SKIP values to validate performance characteristics

📝 Documentation & Code Style

✅ Follows Project Guidelines

  • Adheres to existing code style
  • Single-statement if blocks without braces (per CLAUDE.md)
  • Uses final keyword appropriately
  • No fully qualified names (imports used correctly)
  • Preferred assertion style: assertThat().isEqualTo()

⚠️ Minor Documentation Gap

The helper methods (getMajorVersion, getMinorVersion, getVersionRange) would benefit from Javadoc comments explaining the bit layout, especially since this is a protocol-specific encoding.


🎯 Recommendations

Must Fix

  1. Remove or justify the <excludes>**/*IT.java</excludes> change in pom.xml

Should Fix

  1. Add overflow protection for topKVal = limitVal + skipVal
  2. Document the Neo4j driver version bump rationale
  3. Add Javadoc to version helper methods

Nice to Have

  1. Add a test for very large SKIP values to validate memory behavior
  2. Consider keeping the original cross-session isolation test
  3. Add a comment about the memory trade-off in the Top-K optimization

✅ Final Verdict

Approval Status: Approve with minor changes requested

This is a high-quality PR that fixes a real bug affecting Neo4j 5.x driver compatibility. The test coverage is excellent, and the code follows project conventions. The OpenCypher fix is also important for correctness.

The main concern is the Maven Surefire configuration change, which should be removed or explained. The integer overflow risk should also be addressed.


Great work on the comprehensive testing and clear problem diagnosis! 🎉

@claude
Copy link

claude bot commented Feb 13, 2026

Code Review: Bolt Protocol Version Encoding and Handshake Fix

This PR fixes a critical bug in the Bolt protocol implementation and addresses a related OpenCypher query execution issue. Overall, the changes are well-implemented and ready to merge with some minor observations below.


Strengths

  1. Critical Bug Fix: The version encoding error (0x00000104 vs 0x00000404) would have caused handshake failures with modern Neo4j drivers. This fix is essential.

  2. Comprehensive Test Coverage: The new BoltVersionNegotiationTest.java is excellent:

    • 197 lines of thorough unit tests
    • Tests exact matches, range matching, fallback scenarios, and edge cases
    • Includes realistic scenarios (Neo4j 5.x and 4.x driver handshakes)
    • Well-documented with clear test names
  3. Correct Bolt Spec Implementation: The range-based version negotiation now properly implements the Bolt protocol specification:

    • Correctly extracts major/minor/range from the encoded version
    • Properly handles zero padding (stops iteration on first zero)
    • Follows the algorithm: serverMinor <= clientMinor && serverMinor >= clientMinor - clientRange
  4. OpenCypher Top-K Optimization Fix: The CypherExecutionPlan.java changes correctly implement the Top-K optimization when SKIP and LIMIT are combined:

    • Previously only passed LIMIT to OrderByStep, causing incorrect results when SKIP was present
    • Now passes LIMIT + SKIP as topKVal so enough rows survive pagination
    • Applied consistently across all code paths (4 locations)
  5. Improved Test Quality:

    • BoltProtocolIT.java: Better test structure using modern patterns
    • Transaction isolation test now properly validates rollback behavior
    • Added regression test orderBySkipLimitWithManyNodes matching the Bolt scenario
  6. Dependency Cleanup: Moved neo4j-driver.version to parent POM for better dependency management


🔍 Code Quality Observations

BoltNetworkExecutor.java (bolt/src/main/java/com/arcadedb/bolt/BoltNetworkExecutor.java)

Minor Suggestion: Consider adding explicit bounds checking in the helper methods:

static int getMajorVersion(final int version) {
  return version & 0xFF;
}

static int getMinorVersion(final int version) {
  return (version >> 8) & 0xFF;
}

static int getVersionRange(final int version) {
  return (version >> 16) & 0xFF;
}

These are correct, but adding a comment about the valid range (0-255 for each component) would improve maintainability.

Logging: The existing debug logging at line 205 is good, but consider adding a debug log when a version is successfully negotiated:

if (protocolVersion != 0) {
  LogManager.instance().log(this, Level.FINE, 
      "Negotiated Bolt protocol version %d.%d", getMajorVersion(protocolVersion), getMinorVersion(protocolVersion));
}

CypherExecutionPlan.java (engine/src/main/java/com/arcadedb/query/opencypher/executor/CypherExecutionPlan.java)

Performance Consideration: The Top-K optimization is correctly implemented, but be aware that for queries with large SKIP values and small LIMIT values, the OrderByStep will still materialize SKIP + LIMIT rows in memory. This is unavoidable for correct results but worth documenting.

Code Duplication: The same topKVal calculation appears 4 times in the file:

  • Lines 611-615
  • Lines 1063-1067
  • Lines 1153-1157
  • Lines 1899-1903

Consider extracting to a helper method:

private Integer calculateTopKValue(final Expression skip, final Expression limit, 
    final CommandContext context, final FunctionFactory functionFactory) {
  final Integer skipVal = skip != null ? 
      new ExpressionEvaluator(functionFactory).evaluateSkipLimit(skip, new ResultInternal(), context) : null;
  final Integer limitVal = limit != null ?
      new ExpressionEvaluator(functionFactory).evaluateSkipLimit(limit, new ResultInternal(), context) : null;
  return limitVal != null ? limitVal + (skipVal != null ? skipVal : 0) : null;
}

However, this is not a blocker for merging—the current implementation is clear and correct.


🔒 Security & Performance

  • ✅ No security concerns introduced
  • ✅ No performance regressions (Top-K optimization remains intact)
  • ✅ No new dependencies added
  • ✅ Follows project coding standards (no unnecessary braces, proper use of final)

🧪 Testing

Excellent test coverage:

  • Unit tests for version encoding helpers
  • Unit tests for negotiation algorithm with 12+ scenarios
  • Integration test (queryWithSkipAndLimit) validates end-to-end Bolt protocol
  • Regression test for OpenCypher SKIP/LIMIT combination

Recommendation: Verify that existing Bolt integration tests pass, particularly those using the Neo4j driver.


📋 POM Changes

Issue Found (pom.xml:212-214):

<excludes>
    <exclude>**/*IT.java</exclude>
</excludes>

This excludes ALL integration tests from mvn test. According to the project's CLAUDE.md:

  • mvn test should run unit tests
  • mvn test -DskipITs=false should run integration tests

This change appears unintentional and would break the testing workflow. The skipITs property should control integration test execution, not a hardcoded exclude.

Action Required: Please remove this change or clarify if it's intentional.


Adherence to CLAUDE.md Guidelines

  • ✅ Tests written first (TDD approach followed)
  • ✅ Code adheres to existing style (no unnecessary braces, final keywords used)
  • ✅ No new dependencies added
  • ✅ AssertJ style used: assertThat(x).isEqualTo(y)
  • ✅ No System.out debug statements left behind
  • ⚠️ Needs verification: "Run all connected tests affected by the change"

🎯 Recommendation

Approve with one fix required:

  1. Remove or explain the POM exclude for **/*IT.java (pom.xml:212-214)
  2. ✅ Everything else looks excellent

Once the POM change is addressed, this PR is ready to merge.


📝 Minor Enhancements (Optional)

  1. Add debug logging when version is successfully negotiated
  2. Consider extracting the topKVal calculation to reduce duplication
  3. Add javadoc comments to the version helper methods

Great work on the comprehensive testing and correct implementation! 🚀

@codacy-production
Copy link

codacy-production bot commented Feb 13, 2026

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation Diff coverage
Report missing for 1059e4c1 33.33%
Coverage variation details
Coverable lines Covered lines Coverage
Common ancestor commit (1059e4c) Report Missing Report Missing Report Missing
Head commit (b81c364) 114099 46064 40.37%

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 (#3413) 48 16 33.33%

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 robfrank changed the title fix: correct Bolt protocol version encoding and handshake negotiation fix: correct Bolt protocol version encoding, handshake negotiation and skip limit Feb 13, 2026
@robfrank robfrank merged commit e01a306 into main Feb 13, 2026
18 of 23 checks passed
@robfrank robfrank deleted the fix/bolt-version branch February 13, 2026 14:00
@codecov
Copy link

codecov bot commented Feb 13, 2026

Codecov Report

❌ Patch coverage is 27.08333% with 35 lines in your changes missing coverage. Please review.
✅ Project coverage is 41.81%. Comparing base (89f388a) to head (b81c364).
⚠️ Report is 9 commits behind head on main.

Files with missing lines Patch % Lines
...query/opencypher/executor/CypherExecutionPlan.java 11.11% 31 Missing and 1 partial ⚠️
...in/java/com/arcadedb/bolt/BoltNetworkExecutor.java 75.00% 1 Missing and 2 partials ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##               main    #3413      +/-   ##
============================================
+ Coverage     36.12%   41.81%   +5.68%     
============================================
  Files          1254     1255       +1     
  Lines         84215    84541     +326     
  Branches      17260    17361     +101     
============================================
+ Hits          30423    35351    +4928     
+ Misses        48273    43312    -4961     
- Partials       5519     5878     +359     

☔ 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.

robfrank added a commit that referenced this pull request Feb 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant