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.