[Bug] Vermeer load task fails with "unable to connect" due to missing http:// in URL; after fix, Cardinality code 0 deserialization error

[raled573343]

Bug Type (问题类型)

exception / error (运行异常)

Before submit

• 我已经确认现有的 Server-Issues 与 Computer-Issues 中没有相同 / 重复问题

Environment (环境信息)

We are using HugeGraph 1.7.0 (Server, Store, PD) and Vermeer (latest master). When attempting to load an existing graph into Vermeer via the load task, the following error occurs in the worker logs:

[ERROR] "hugegraph server address unable to connect :[],[],[]"

After investigating, we found that Vermeer's testServerIsValid and getHugegraphSchema functions (in vermeer/apps/common/hugegraph_tools.go) construct the server URL without the http:// prefix, e.g.:

url := fmt.Sprintf("%v/graphspaces/%v/graphs/%v/schema?format=json", addr, hgSpace, hGraph)

This results in an invalid URL and the HTTP client fails to connect.

We manually patched both occurrences to include http:// (or added a prefix check) and rebuilt the Vermeer image. After that, Vermeer could successfully contact the server and started reading data from the Store. However, a new error appeared on the Store side:

java.lang.IllegalArgumentException: Can't construct Cardinality from code 0
  at org.apache.hugegraph.type.define.SerialEnum.fromCode(SerialEnum.java:50)
  at org.apache.hugegraph.serializer.BytesBuffer.readProperty(...)
  at org.apache.hugegraph.serializer.BinaryElementSerializer.parseVertex(...)
The worker logs show that reading vertices fails with rpc error: code = Unknown desc = "" and the task eventually fails.

Environment:

• HugeGraph Server: 1.7.0 (Docker image hugegraph/hugegraph:1.7.0)
• HugeGraph Store: 1.7.0 (Docker image hugegraph/store:latest)
• HugeGraph PD: 1.7.0 (Docker image hugegraph/pd:latest)
• Vermeer: built from latest master branch of apache/hugegraph-computer
• Deployment: Docker Compose with services as described in the attached docker-compose.yml.

Steps to reproduce:

• Deploy HugeGraph PD, Store, Server, and Vermeer (Master + Worker) using the provided Docker Compose.
• Load some sample data into the graph (e.g., using test.py).
• Register the HugeGraph Server with the PD using a custom gRPC script (since apparently the server does not auto-register in this setup). This script sends register and heartbeat via DiscoveryService with labels {"GRAPHSPACE": "DEFAULT"}.
• Create a Vermeer load task via REST API:

curl -X POST http://localhost:5001/tasks/create \
-H "Content-Type: application/json" \
-d '{
"task_type": "load",
"worker_group": "default",
"graph": "my_graph_noreggroup",
"params": {
  "load.parallel": "50",
  "load.type": "hugegraph",
  "load.hg_pd_peers": "[\"pd:8686\"]",
  "load.hugegraph_name": "DEFAULT/hugegraph/g",
  "load.hugegraph_username": "admin",
  "load.hugegraph_password": "admin",
  "load.use_out_degree": "1",
  "load.use_outedge": "1",
  "load.use_property": "1"
},
"timeout": 60
}' -b cookies.txt

• Observe the worker logs – the first error occurs.
• Patch the two fmt.Sprintf calls in hugegraph_tools.go to include http://, rebuild the image, and redeploy.
• Re-run the load task – the second error (Cardinality) appears.

Logs (excerpts):

Before patch (worker):

vermeer-worker | 26-09-02 06:28:11 [ERROR] "hugegraph server address unable to connect :[],[],[]"

After patch (worker):

vermeer-worker | 26-09-02 07:10:43 [INFO] "start read part: hugegraph: DEFAULT/hugegraph/g, partition_id: 0, store address: store:8500, start_key: 0, end_key: 5462"
...
vermeer-worker | 26-09-02 07:10:43 [ERROR] "graph load task error: taskId:1, graph: my_graph_noreggroup"
vermeer-worker | 26-09-02 07:10:43 [ERROR] "read vertex error: rpc error: code = Unknown desc = "

Store logs:

java.lang.IllegalArgumentException: Can't construct Cardinality from code 0
  at org.apache.hugegraph.type.define.SerialEnum.fromCode(SerialEnum.java:50)
  at org.apache.hugegraph.serializer.BytesBuffer.readProperty(...)
  at org.apache.hugegraph.serializer.BinaryElementSerializer.parseVertex(...)

Analysis:

1. Missing http://: This is a clear bug. The URL must include a scheme for the Go HTTP client to work. The fix is to add http:// (or https://) to the URL in both testServerIsValid and getHugegraphSchema. We have already verified that this fixes the connection issue.
2. Cardinality code 0: After the connection is established, the Store fails to deserialize vertices because it encounters an invalid cardinality value 0. The SerialEnum.fromCode method expects codes starting from 1 (SINGLE, LIST, SET, etc.). This suggests that either:

• The data stored in the Store is corrupted or written with a different serialization format.
• There is a version mismatch between the Store (1.7.0) and the Vermeer client (which may use a newer/older proto definition).
• The graph schema does not match the data (e.g., properties have unexpected cardinalities).

It is worth noting that we had to manually register the Server with PD using a custom script; in a normal production environment, the Server should auto-register. Perhaps the lack of registration or incorrect registration (e.g., missing GRAPHSPACE label) might affect the data retrieval.

Proposed fixes:

Fix 1 (immediate): Add http:// prefix to URLs in hugegraph_tools.go (both occurrences). This will resolve the connectivity problem.

Fix 2 (needs investigation): Investigate why the Store returns data with cardinality 0. Possible actions:

Ensure all components (Server, Store, PD, Vermeer) are built from the exact same release tag (e.g., 1.7.0) to guarantee protocol compatibility.

Check if the data was written correctly; maybe the test.py script uses an older schema that does not define cardinalities properly.

Enable debug logging in the Store to see the raw bytes being parsed and identify which property triggers the error.

Confirm that the graph name used in the load task (DEFAULT/hugegraph/g) matches the actual graph space and graph where data resides.

Additional context:

We observed that the Server does not automatically register with PD in our Docker setup; we had to use a Python script (grpc_check.py) to manually send register and heartbeats. This might be related to the environment variables or configuration of the Server. If auto-registration is the expected behavior, this could be another bug.

Attachments:

docker-compose.yml – Compose file used for deployment.

vermeer-master.ini and vermeer-worker.ini – Configuration files.

grpc_check.py – Script used to manually register the Server.

Request:

Please address the missing http:// issue as a priority, and also investigate the Cardinality deserialization error. If the latter is a version mismatch, please clarify the correct version alignment and document it.

Expected & Actual behavior (期望与实际表现)

docker-compose.yml
vermeer-master.ini.txt
vermeer-worker.ini.txt

[dosubot]

Hi @raled573343! I'm Dosu and I'm helping the HugeGraph team.

I checked the code for both issues you reported.

1. Missing http:// prefix — confirmed bug

Both testServerIsValid and GetHugegraphSchema in vermeer/apps/common/hugegraph_tools.go build request URLs by directly concatenating the bare addr value (a host:port string from PD's DiscoveryService.GetNodes) with the path — no scheme prefix is added. Go's net/http client requires an absolute URL including scheme, so the request will fail for any address lacking http:// or https://. Your fix (prefixing with http:// or adding a prefix check) is correct. This looks like a good candidate for a PR.

2. Can't construct Cardinality from code 0 — Store-side deserialization issue

Cardinality is a SerialEnum with valid codes starting at 1 (SINGLE(1), LIST(2), SET(3)) — there is no code 0 [1]. SerialEnum.fromCode throws the exact error you're seeing when a code isn't in its registered table [2]. Since the stack trace is java.lang.IllegalArgumentException from org.apache.hugegraph.type.define.SerialEnum, this error occurs inside the Store process when it deserializes its own on-disk vertex data (BinaryElementSerializer.parseVertex) to answer the gRPC ScanPartition request — before the data ever reaches Vermeer.

A cardinality code of 0 typically means the parser is reading a byte that was never written as a cardinality/type header for the property being read — likely a byte offset or property-key ID mismatch rather than random data corruption. This points at a schema or storage-layer issue on the Store side.

Notably, there is a related graph ID isolation bug in HStore 1.7.0 where multiple graphs can inadvertently share the same internal key prefix, causing data from one graph to be visible to another. A community fix is in progress (PR #163 in the community repo). If your graph data was written while this bug was present, the Store could be reading vertices whose internal binary layout doesn't match the schema of the graph being queried — which would produce exactly the Cardinality code 0 error you're seeing.

On the Vermeer side, ReadVertex → PropertyValue.LoadFromHugegraph maps prop.Label to an index via schema.HgPSchema.PropIndex and expects already-typed Variant data from the Store's gRPC response [3] [4], so Vermeer itself is not constructing the cardinality — it consumes properties after the Store has already deserialized them.

On the missing auto-registration: PdRegister.registerService does exist and registers the Server with PD including a GRAPHSPACE label [5]. I wasn't able to fully trace the startup condition that triggers this automatically in your Docker Compose setup, so I can't confirm whether needing manual grpc_check.py registration reflects a gap in auto-registration or a configuration issue specific to your deployment.

Recommendations:

• Submit a PR for the http:// prefix fix in hugegraph_tools.go — it's small and clearly correct.
• For the Cardinality error, check whether the HStore graph ID isolation bug applies to your setup (fresh data directories with multiple graphs). If so, tracking the community fix (PR 怎样设定合适的cpu和内存来运行算法 #163) may resolve this.
• If you're using a single graph, enabling debug logging on the Store around BinaryElementSerializer.parseVertex/parseProperty to log the raw property-key ID and header byte at the failing offset would help narrow down whether it's a schema mismatch vs. a format incompatibility.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.