TEST !!

[bitflicker64]

Bug Type (问题类型)

None

Before submit

• 我已经确认现有的 Issues 与 FAQ 中没有相同 / 重复问题 (I have confirmed and searched that there are no similar problems in the historical issue and documents)

Environment (环境信息)

• Server Version: 1.0.0 (Apache Release Version)
• Backend: RocksDB x nodes, HDD or SSD
• OS: xx CPUs, xx G RAM, Ubuntu 2x.x / CentOS 7.x
• Data Size: xx vertices, xx edges

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

Expected & Actual behavior (期望与实际表现)
The memberSize field in the response from GET / (IndexAPI) always returns 0
regardless of how many PD nodes are actually in the cluster.

Actual:
curl -u store:store http://localhost:8620/
{"state":"Cluster_Not_Ready","leader":"pd2:8686","memberSize":0,"storeSize":3,...}

Expected:
memberSize should return 3 for a 3-node PD cluster.

Root cause:
IndexAPI.index() sets storeSize, graphSize, partitionSize, leader but never
sets memberSize on the BriefStatistics object. The field defaults to 0.

The /v1/cluster endpoint in the same file does it correctly:
statistics.memberSize = pdList.size();

Fix: add the equivalent line in index() using
RaftEngine.getInstance().getMembers().size()

Vertex/Edge example (问题点 / 边数据举例)

Schema [VertexLabel, EdgeLabel, IndexLabel] (元数据结构)

[github-actions]

Comment on Issue

It appears that the memberSize field in the response from the GET / endpoint is not being set correctly, resulting in a value of 0. As you've pointed out, the IndexAPI.index() method is likely the culprit, as it sets other fields like storeSize, graphSize, and leader, but not memberSize.

The proposed fix, adding a line to index() to set memberSize using RaftEngine.getInstance().getMembers().size(), seems plausible and aligns with how member size is retrieved and used in other parts of the codebase, such as in MemberAPI.getMembers() and PDService.getMembersAndClusterState().

Before proceeding with the fix, it would be helpful to verify the implementation of IndexAPI.index() and the BriefStatistics object to ensure that the proposed change will indeed resolve the issue.

Next Steps

To move forward, please provide more information about the IndexAPI class and its index() method, or confirm that the proposed fix resolves the issue.

Note: I am an AI bot powered by DeepWiki + Groq, and I'm here to help. If you have any follow-up questions or need further assistance, feel free to ask!

---

✅ Powered by DeepWiki + Groq — answer based on actual repo documentation.

[bitflicker64]

Comment on Issue

It appears that the memberSize field in the response from the GET / endpoint is not being set correctly, resulting in a value of 0. As you've pointed out, the IndexAPI.index() method is likely the culprit, as it sets other fields like storeSize, graphSize, and leader, but not memberSize.

The proposed fix, adding a line to index() to set memberSize using RaftEngine.getInstance().getMembers().size(), seems plausible and aligns with how member size is retrieved and used in other parts of the codebase, such as in MemberAPI.getMembers() and PDService.getMembersAndClusterState().

Before proceeding with the fix, it would be helpful to verify the implementation of IndexAPI.index() and the BriefStatistics object to ensure that the proposed change will indeed resolve the issue.

Next Steps

To move forward, please provide more information about the IndexAPI class and its index() method, or confirm that the proposed fix resolves the issue.

Note: I am an AI bot powered by DeepWiki + Groq, and I'm here to help. If you have any follow-up questions or need further assistance, feel free to ask!

✅ Powered by DeepWiki + Groq — answer based on actual repo documentation.

so what is the actual fix

[github-actions]

Issue Summary

The issue title "TEST !!" and body "so what is the actual fix" suggest that you're looking for a solution to a problem, but the problem itself hasn't been specified.

General Troubleshooting Steps

To assist you better, here are some general steps for troubleshooting common issues in the Apache HugeGraph ecosystem, particularly in Docker deployments:

1. Check Resource Limitations: Ensure that Docker Desktop has sufficient memory allocated (at least 12 GB for 9 JVM processes).
2. Verify Network Connectivity: Confirm that all PD nodes can reach each other on the Raft port (8610) and that HG_PD_RAFT_PEERS_LIST is correctly configured.
3. Inspect Container Logs: Use docker logs to check for errors or warnings in PD, Store, or Server containers.
4. Review Configuration Files: Ensure consistency across all nodes in configuration files like docker-compose-3pd-3store-3server.yml.

Specific Fixes

Without a specific issue, here are fixes for common problems:

• Containers Exiting or Restarting (OOM Kills): Increase Docker Desktop memory.
• Raft Leader Election Failure: Verify PD nodes can communicate, check HG_PD_RAFT_PEERS_LIST, and ensure network connectivity.
• Partition Assignment Not Completing: Wait for partition assignment, check registered stores and partition status.

Next Steps

For more targeted assistance, please provide details about the issue you're facing, such as error messages, symptoms, or the context in which the problem occurs.

Note: I'm an AI bot powered by DeepWiki + Groq, here to help answer your questions about the Apache HugeGraph project. Feel free to ask follow-up questions or provide more details about your issue for a more precise response.

---

✅ Powered by DeepWiki + Groq — answer based on actual repo documentation.