[Bug] test: restore strict assertion for backend_metrics in test_metric.py

[Muawiya-contact]

Bug Type (问题类型)

None

Before submit

• I had searched in the issues and found no similar issues.

Environment (环境信息)

Environment

Item	Detail
HugeGraph Server	1.7.0
Module	python-client
File	hugegraph-python-client/src/tests/test_metric.py

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

---

Expected & Actual Behavior

Problem

test_metrics_operations (L78–79) contains an if "hugegraph" in backend_metrics: guard that effectively no-ops the backend metrics assertion when running against HugeGraph 1.7.0.

This means shape drift in the API response goes completely undetected — the test passes silently even if the backend metrics structure changes.

Expected

The test should pin the actual 1.7.0 response shape and assert against it deterministically. Any deviation from the known shape should surface as a test failure.

Actual

The guard short-circuits the assertion. On HugeGraph 1.7.0, the block inside the if is never entered, so the backend metrics structure is never validated.

---

Suggested Fix

1. Document the actual backend_metrics response shape returned by HugeGraph 1.7.0.
2. Replace the open-ended guard with a version-gated deterministic assertion — e.g.:

# Before (no-op guard)
if "hugegraph" in backend_metrics:
    assert ...

# After (strict, version-aware assertion)
assert "hugegraph" in backend_metrics, (
    f"Expected 'hugegraph' key in backend_metrics, got: {list(backend_metrics.keys())}"
)
assert backend_metrics["hugegraph"] == EXPECTED_SHAPE_1_7_0

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

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

[Muawiya-contact]

@imbajin, can you just verify that one, please? If everything is okay, assign it to me.

[Muawiya-contact]

Implementation Plan — #326

Goal

Replace the no-op guard in test_metric.py with a deterministic assertion so shape drift in backend_metrics surfaces as a failure, not a silent pass.

---

Steps

1. Run test_metrics_operations against HugeGraph 1.7.0 and print the raw backend_metrics response to capture the actual shape
2. Pin that shape as a constant — e.g. EXPECTED_SHAPE_1_7_0 = { ... }
3. Replace the if "hugegraph" in backend_metrics: guard with a hard assertion:

   assert "hugegraph" in backend_metrics, (    f"Expected 'hugegraph' key, got: {list(backend_metrics.keys())}")assert backend_metrics["hugegraph"] == EXPECTED_SHAPE_1_7_0
   

4. Version-gate if needed — add a branch for other known server versions with their own pinned shapes
5. Run the test suite to confirm it passes on 1.7.0 and fails on a deliberately broken shape
6. Open PR referencing [Bug] test: restore strict assertion for backend_metrics in test_metric.py #326, # fix: implement graphspace-scoped auth routing in Python client #325, Upgrade HugeGraph Python Client CI from 1.3.0 to 1.7.0 #320

---

Scope

Item	Detail
File	hugegraph-python-client/src/tests/test_metric.py
Lines	L78–79 (test_metrics_operations)
Server	HugeGraph 1.7.0
Labels	test python-client

[dosubot]

Hi @Muawiya-contact — I looked into the current state of test_metric.py and it appears the issue you're describing doesn't match what's currently on main. The file is 74 lines long and line 72–73 already uses a direct assertion without a conditional guard:

backend_metrics = self.metrics.get_backend_metrics()
self.assertGreater(len(backend_metrics["hugegraph"]), 1)

There is no if "hugegraph" in backend_metrics: guard in the current implementation [1]. The assertion will raise a KeyError if the "hugegraph" key is missing, and will fail if the value has fewer than 2 entries.

That said, this assertion is still fairly loose — it only checks that the list/dict has more than 1 element, without validating the actual response shape. Your suggestion to pin the expected 1.7.0 structure is reasonable, and it aligns well with the work tracked in issue #319 (upgrading CI to HugeGraph 1.7 and tightening test assertions), which you're already assigned to.

If you'd like to strengthen this as part of that effort, you could:

1. Capture the actual backend_metrics["hugegraph"] structure from a 1.7.0 server
2. Assert specific keys/shape rather than just length

Could you double-check which branch or fork you're seeing the if "hugegraph" in backend_metrics: guard on? It's possible it exists in a local branch or was part of a draft that wasn't merged.

Written by @dosu, approved by imbajin

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[Muawiya-contact]

Thanks @dosu for checking — I've now had this independently verified
by GitHub Copilot against the current main branch. Here's what it confirmed:

1. Guard is present — if "hugegraph" in backend_metrics: exists and
   is flagged as a backward-compatibility workaround
2. Assertion at L72–73 — only checks len > 1, no structural validation
3. No shape validation — the only checks are:
   • assertIsInstance(backend_metrics, dict) — type only
   • assertTrue(backend_metrics) — existence only
   • The conditional guard itself

Shape drift inside backend_metrics["hugegraph"] would pass silently.
My original fix stands — pinning the actual 1.7.0 response shape and
replacing the guard with a deterministic structural assertion.

Happy to proceed with the fix as described above. Please assign. 🙏

[dosubot]

@Muawiya-contact — I appreciate the follow-up, but I've done a second independent search and my finding remains the same: the if "hugegraph" in backend_metrics: guard does not exist in test_metric.py on the current main branch [1]. The file is 74 lines long — there are no lines 78–79. What's there is:

backend_metrics = self.metrics.get_backend_metrics()
self.assertGreater(len(backend_metrics["hugegraph"]), 1)

No conditional guard, no assertIsInstance(backend_metrics, dict), no assertTrue(backend_metrics) — just a direct key access and a length check.

That said, your core point about strengthening the assertion to validate the actual structure (not just len > 1) is still a valid improvement. Pinning the expected 1.7.0 response shape would catch structural drift that the current loose length check misses. That work fits naturally into issue #319 (CI upgrade + tightening assertions) which you're already working on.

I'd suggest confirming with @imbajin whether this should be a separate PR or folded into your #319 effort, since the scope overlaps significantly.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[Muawiya-contact]

Thanks @dosu — I accept the correction. The guard isn't there on main.

The core concern still stands though: assertGreater(len(backend_metrics["hugegraph"]), 1)
only validates length, not structure. Shape drift would still pass silently.

@imbajin — should I fold the structural assertion improvement into #319,
or keep it as a separate PR? Happy to go either way.

[dosubot]

@Muawiya-contact — Agreed, the structural validation gap is real. Since the fix is tightly coupled to knowing the actual 1.7.0 response shape (which you'll discover while working on #319's CI upgrade anyway), folding it into #319 seems like the cleaner path — one PR that upgrades the server and tightens the assertions against the new baseline. That avoids a situation where a separate PR here pins a shape you haven't yet confirmed against the upgraded CI.

That said, this is ultimately @imbajin's call on how they'd like the work organized.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[Muawiya-contact]

Thanks @dosu — that makes sense. Folding the structural assertion fix into #319
is cleaner: I'll confirm the actual 1.7.0 backend_metrics shape during the CI
upgrade, then pin and assert against it in the same PR.

@imbajin — happy to proceed that way. Should I close #326 and track this
under #319, or keep it open as a reference?

[dosubot]

@Muawiya-contact — Sounds like a solid plan. I'd suggest keeping #326 open as a reference and linking it from your #319 PR (e.g., "Resolves #326") so it auto-closes when the PR merges. That way the context and discussion here stays discoverable, and you get clean traceability. But again, @imbajin's preference takes priority.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.