[Task] Upgrade CI HugeGraph server to 1.7 and adapt tests

[imbajin]

Background

The current python-client CI workflow still starts hugegraph/hugegraph:1.3.0 in .github/workflows/hugegraph-python-client.yml. The file already carries a TODO for upgrading the server version, and PR #318 had to add a compatibility gate around /metrics/system because the legacy server returns 500 there.

Task

Upgrade the HugeGraph server used by python-client CI to 1.7, then adapt the client tests and compatibility assumptions to the newer server behavior.

Scope

• Update the workflow image tag from 1.3.0 to 1.7.x in .github/workflows/hugegraph-python-client.yml.
• Revisit python-client integration tests that currently encode old-server behavior.
• Remove temporary compatibility gates once CI runs against the newer server version.
• Verify the latest client code paths against HugeGraph 1.7 responses and error handling.

Acceptance Criteria

• python-client CI runs against HugeGraph 1.7 successfully.
• tests reflect current server behavior instead of legacy 1.3.0 quirks.
• any required client-side adjustments for 1.7 are included and documented in the PR.

Notes

• Recent context: PR refactor: remove 'incubating' branding, update docs & packaging #318 (refactor: remove 'incubating' branding, update docs & packaging) exposed that the workflow is still pinned to an old server image.\n- If 1.7 introduces API or payload differences, please update the relevant tests first and then tighten the assertions around the new behavior.
• Use https://docs.github.com/en/actions/tutorials/use-containerized-services/use-docker-service-containers to replace docker pull cmd in ci

[Muawiya-contact]

Hi @imbajin,

I’m interested in working on this task.

From my understanding, this involves upgrading the HugeGraph server in the CI workflow to version 1.7.x and updating the integration tests to match the newer server behavior, including removing temporary compatibility workarounds.

Before I start, I’d like to confirm:

• Should I fully remove all compatibility gates related to the 1.3.0 behavior once tests pass on 1.7?
• Is there any preferred version within 1.7.x to target?

I’d be happy to take this on. Please let me know if that works.

Thanks!

[imbajin]

Hi @imbajin,

I’m interested in working on this task.

From my understanding, this involves upgrading the HugeGraph server in the CI workflow to version 1.7.x and updating the integration tests to match the newer server behavior, including removing temporary compatibility workarounds.

Before I start, I’d like to confirm:

• Should I fully remove all compatibility gates related to the 1.3.0 behavior once tests pass on 1.7?
• Is there any preferred version within 1.7.x to target?

I’d be happy to take this on. Please let me know if that works.

Thanks!

Hi @Muawiya-contact , after further consideration, let's refine the strategy to handle the breaking changes more cleanly:

1. Target Version: Use 1.7.0 as the primary stable version for this update.

2. Compatibility Strategy:

   • Focus on 1.7: We will treat version 1.7 as the standard for current API and data structure adaptations (including the storage format changes). [Also we need to update the version & usage in hugegraph-llm modules]
   • Clean up Legacy Code: You can remove old compatibility "tricks" and workarounds that were kept for much older versions. We want to keep the codebase clean.
   • Version Guard: Since there are breaking changes (storage/tables) between 1.3 and 1.5/1.7, we should implement a version check. If the detected HugeGraph Server version is < 1.5, the client should prompt the user to either upgrade their server or use an older version of py-client (v1.3.x).

3. Key Implementation Details:

   • Breaking Changes: Note that in post-1.3 versions, the edge structure has changed (e.g., an additional part in the composition). Integration tests need to be adjusted to match these 1.7+ behaviors.
   • References: You can refer to the Java-Client repository for how it handled these adaptations, and check DeepWiki for specific data structure changes.

This approach ensures the best support for the latest server while giving a clear path for legacy users. Let me know if you have any questions!

[Muawiya-contact]

Hi @imbajin,

Got it — I understand the approach (target 1.7.0, remove old workarounds, add version guard, update tests).

I’d like to work on this. Could you please assign it to me?

Thanks!

[Muawiya-contact]

My ICLA license is under review. Once it is completed, I will open a PR for that.