fix: support new HugeGraph edge id format

[hutiefang76]

Purpose of the PR

• close [Bug] The edge id is formatted by 5 instead of 4 parts #324

HugeGraph server now formats edge ids with 5 or 6 parts after the parent/child edge label change. The computer loader still called Edge.name() from the older client, which expects exactly 4 parts and can fail while loading edges for algorithms such as LPA.

Main Changes

• Add HugeConverter.convertEdgeName() to read sort values from 4-part, 5-part, and 6-part edge ids.
• Use the converter in LoadService instead of calling edge.name() directly.
• Add regression coverage for both 5-part and 6-part edge id formats.

Verifying these changes

• Trivial rework / code cleanup without any test coverage. (No Need)
• Already covered by existing tests, such as (please modify tests here).
• Need tests and can be verified as follows.

mvn -pl computer-test -am -Djacoco.skip=true \
  -Dtest=HugeConverterTest#testConvertEdgeNameWithFivePartEdgeId+testConvertEdgeNameWithSixPartEdgeId \
  -Dsurefire.failIfNoSpecifiedTests=false test

mvn -pl computer-test -am -Djacoco.skip=true \
  -Dtest=HugeConverterTest \
  -Dsurefire.failIfNoSpecifiedTests=false test

Does this PR potentially affect the following parts?

• Nope
• Dependencies (add/update license info)
• Modify configurations
• The public API
• Other affects (typed here)

Documentation Status

• Doc - TODO
• Doc - Done
• Doc - No Need

[imbajin]

The fix is in the right area, but the compatibility logic should mirror the java-client edge-id semantics more directly and lock the legacy path with a test.

[imbajin]

❗️ High priority: please align this parser with the java-client edge-id invariant instead of hardcoding each length/index pair.

Context

• Legacy client 1.3 parsed the old 4-part id as parts[2].
• Current toolchain java-client parses the permanent 5/6-part formats in Edge.name() as idParts[idParts.length - 2] after validating the part count.
• So the stable semantic is: Computer's edge name is the edge sort-values segment, i.e. the penultimate part of a valid edge id.

Risk

The current implementation encodes the same rule as 4 -> parts[2], 5 -> parts[3], and 6 -> parts[4]. That works for these examples, but it re-implements java-client parsing in a more fragile form and makes future format/client upgrades easier to drift.

Suggestion

Keep the compatibility range explicit, but extract through the shared invariant:

if (parts.length >= 4 && parts.length <= 6) {
    return parts[parts.length - 2];
}

Please also add a 4-part regression test beside the new 5/6-part tests, since this method explicitly preserves HugeGraph 1.3 compatibility but the current coverage only locks the new formats.

[imbajin]

❗️ Please also update the CI HugeGraph environment after fixing the parser.

🔗 Reference: computer-ci.yml

Context

• The current workflow still runs integration tests with GRAPH_ENV_VERSION: 1.3.0.
• The adjacent TODO still says to adapt Server/Loader to 1.5.0, but the current release line is already 1.7.0.
• GRAPH_ENV_VERSION is passed into load-data-into-hugegraph.sh, which starts both:
  • hugegraph/hugegraph:${GRAPH_ENV_VERSION}
  • hugegraph/loader:${GRAPH_ENV_VERSION}

Required update

Please update the workflow to use the latest 1.7.0 HugeGraph Server/Loader images and remove the stale TODO, for example:

GRAPH_ENV_VERSION: 1.7.0

Test completeness

After that, the related coverage should prove both compatibility directions:

• unit tests cover legacy 4-part edge ids;
• unit tests cover current 5/6-part edge ids;
• CI integration tests actually load data through HugeGraph Server/Loader 1.7.0, so this PR is validated against the permanent edge-id format rather than only the old 1.3.0 environment.

[hutiefang76]

Updated in 91a04d9:

• Kept legacy 4-part edge ids on the existing Edge.name() path.
• Added coverage for legacy 4-part ids, current 5-part ids, and both EDGE_OUT / EDGE_IN 6-part ids.
• Switched GRAPH_ENV_VERSION to 1.7.0 and removed the stale 1.5.0 TODO.

Local checks:

mvn -pl computer-test -am -Djacoco.skip=true -Dtest=HugeConverterTest -Dsurefire.failIfNoSpecifiedTests=false test
git diff --check -- .github/workflows/computer-ci.yml computer/computer-core/src/main/java/org/apache/hugegraph/computer/core/input/HugeConverter.java computer/computer-test/src/main/java/org/apache/hugegraph/computer/core/input/HugeConverterTest.java

The new GitHub Actions runs are currently waiting for workflow approval (action_required).

[imbajin]

Blocking: yes. Summary: Legacy edge-id compatibility still depends on client-version behavior, and latest Computer CI is cancelled. Evidence: JDK 11 HugeConverterTest passed locally; current-head computer-ci cancelled.

---

🔗 Please check the cancelled current-head Computer CI run: https://github.com/apache/hugegraph-computer/actions/runs/27905173009/job/82572760266

[imbajin]

⚠️ Keep legacy id parsing inside the shim

convertEdgeName() already splits the id, but the 4-part branch still delegates to edge.name(). That only works with the current hugegraph-client 1.3.0 dependency; the current java-client implementation only accepts 5/6-part ids and derives the name from idParts[idParts.length - 2], so this compatibility shim will break for legacy ids when the client dependency is aligned with the 1.7.0 runtime that this PR now validates against.

Please return parts[2] for LEGACY_EDGE_ID_PARTS directly, or use the shared parts[parts.length - 2] invariant for all accepted arities, and leave edge.name() only for null or unknown formats.

[imbajin]

Blocking: no. Summary: No obvious issues found in the current head. Evidence: git diff --check passed; HugeConverterTest and HugeClientCompatibilityTest passed (8 tests); latest gh pr checks reported no checks.

[codecov]

Codecov Report

❌ Patch coverage is 84.61538% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 84.98%. Comparing base (e0b484a) to head (b84879d).
⚠️ Report is 39 commits behind head on master.

Files with missing lines	Patch %	Lines
...e/hugegraph/computer/core/input/HugeConverter.java	57.14%	2 Missing and 4 partials ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master     #349      +/-   ##
============================================
- Coverage     85.03%   84.98%   -0.05%     
- Complexity     3296     3375      +79     
============================================
  Files           349      361      +12     
  Lines         12485    12716     +231     
  Branches       1130     1157      +27     
============================================
+ Hits          10616    10807     +191     
- Misses         1329     1340      +11     
- Partials        540      569      +29     

☔ View full report in Codecov by Harness.
📢 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.

[hutiefang76]

I checked the current computer-ci failure. The HeartbeatHandlerTest failure is reproducible on upstream master with the same JDK 11 container command, so it does not look specific to this edge-id change.

Command used on both this branch and upstream/master:

docker run --rm -v <repo>:/workspace -w /workspace maven:3.8.8-eclipse-temurin-11 \
  mvn -f computer/pom.xml -pl computer-test -am -P unit-test \
  -Dtest=NettyTransportClientTest,HeartbeatHandlerTest \
  -Djacoco.skip=true -Dsurefire.failIfNoSpecifiedTests=false test

Result:

• NettyTransportClientTest passed locally in the JDK 11 container.
• HeartbeatHandlerTest.testHeartbeatHandler failed on both branches with Wanted 4 times ... But was 3 times.

I will keep this PR scoped to the edge-id compatibility fix unless you prefer me to include a separate flaky-test stabilization change here.

[imbajin]

Requesting changes for the edge-id compatibility path. CI is green now, but the regression test still does not cover the server-generated 6-part directional ID format.

Reference context:

• Server writes directed 6-part edge IDs in EdgeId.asString() via this.direction.type().string(): https://github.com/apache/hugegraph/blob/master/hugegraph-struct/src/main/java/org/apache/hugegraph/id/EdgeId.java#L146-L157
• Server direction tokens are O / I, not enum names: https://github.com/apache/hugegraph/blob/master/hugegraph-struct/src/main/java/org/apache/hugegraph/type/HugeType.java#L53-L57
• Server parses the 6-part direction with HugeType.fromString(idParts[1]): https://github.com/apache/hugegraph/blob/master/hugegraph-struct/src/main/java/org/apache/hugegraph/id/EdgeId.java#L276-L283
• Current java-client derives the edge name from the penultimate segment for both 5/6-part IDs: https://github.com/apache/hugegraph-toolchain/blob/master/hugegraph-client/src/main/java/org/apache/hugegraph/structure/graph/Edge.java#L142-L149

The expected invariant is:

server 6-part directed edge id
ownerVertexId > O/I > edgeLabelId > subLabelId > sortValues > otherVertexId
                  ^                              ^
                  |                              |
        server direction token           edge name / sort values

java-client 1.7 Edge.name(): parts[parts.length - 2]
computer current guard:       accepts EDGE_OUT / EDGE_IN only

So the compatible parser should accept the server tokens O and I, or more simply follow the java-client invariant and return the penultimate segment for known 5/6-part edge IDs while keeping the 4-part legacy branch.

[imbajin]

❗️ High priority: this still does not parse the server-generated 6-part edge ID format correctly.

This branch only accepts parts[1] when it is EDGE_OUT or EDGE_IN, but server-side EdgeId.asString() writes the direction via this.direction.type().string(). In HugeGraph those values are O / I, not the enum names:

• server writer: https://github.com/apache/hugegraph/blob/master/hugegraph-struct/src/main/java/org/apache/hugegraph/id/EdgeId.java#L146-L157
• server direction tokens: https://github.com/apache/hugegraph/blob/master/hugegraph-struct/src/main/java/org/apache/hugegraph/type/HugeType.java#L53-L57
• server parser: https://github.com/apache/hugegraph/blob/master/hugegraph-struct/src/main/java/org/apache/hugegraph/id/EdgeId.java#L276-L283

So a valid current server ID like S1:178201>O>5>5>参数标准!3BA0>S4:239464 will skip this branch and fall back to edge.name(). That fallback is not safe here because Computer still depends on hugegraph-client 1.3.0, whose Edge.name() only supports the legacy 4-part ID format.

The current java-client invariant is also simpler: for 5/6-part IDs, Edge.name() returns the penultimate segment: https://github.com/apache/hugegraph-toolchain/blob/master/hugegraph-client/src/main/java/org/apache/hugegraph/structure/graph/Edge.java#L142-L149

ownerVertexId > O/I > edgeLabelId > subLabelId > sortValues > otherVertexId
                                                ^
                                      expected edge name

Please align this parser with that invariant, or at least validate against the server tokens O and I. The regression tests should cover both >O> and >I> forms and prove that valid 6-part IDs do not fall back to the old client parser.

[imbajin]

⚠️ Please avoid making current java-client fields globally ignorable.

This compatibility module ignores edgelabel_type, parent_label, and links for every EdgeLabel deserialization. That works for the pinned 1.3 client because those fields are unknown there, but in current java-client 1.7 they are real fields: sourceLabel() / targetLabel() derive from links.

A more version-tolerant approach would ignore unknown fields rather than explicitly dropping known current fields, for example with an @JsonIgnoreProperties(ignoreUnknown = true) mix-in, or by conditionally adding ignorables only when the runtime EdgeLabel class does not expose those fields. The tests should prove both sides: old client does not fail on new server fields, and current client semantics do not lose links.

[imbajin]

Blocking: no. Summary: No obvious issues found in the current head. Evidence: git diff --check passed; JDK 11 HugeConverterTest,HugeClientCompatibilityTest passed (12 tests); no visible checks reported for this branch.