fix(helm): detect invalid indexes per server pod

[imbajin]

Purpose of the PR

helm test can pass every Server while one Pod retains an unready index state and indexed queries fail. The hook previously checked only graph binding and a simple scan. It now checks visible linked index state on every Pod, with optional explicit business-query assertions.

Main Changes

• Read associated indexes by ID through the query cache path, without refreshing the full index cache and masking stale state. Require CREATED, including rejection of stale CREATING and REBUILDING; retain the existing retry deadline.
• Add server.testGremlin for existing-data assertions, supplied with --set-file. Failures identify the Pod IP, check stage and response; unconfigured business assertions are reported as skipped.
• Run the rendered query in CI using the Groovy version from the Server POM, with missing execution coverage treated as failure.
• Create no schema/data by default. Run after index jobs finish with no concurrent schema changes: on HStore, reading an unfinished index can cache a stale status on other Pods; retries do not refresh it. Document coverage limits and custom-script credentials.

Verifying these changes

• Need tests and can be verified as follows: Helm template/package checks, preset lint, Kubernetes 1.23 schemas, command fixtures, real Groovy execution of the rendered query, Java 17 formatting and compilation pass. The final diff received independent review. No local services, listeners, containers or clusters were started; live-cluster acceptance remains pending.

Does this PR potentially affect the following parts?

• Dependencies
• Modify configurations
• The public API
• Other affects (Helm test coverage and diagnostics)
• Nope

Documentation Status

• Doc - TODO
• Doc - Done: repository README, operations guide and values; bilingual website update is included in docs: explain easy Helm deployments hugegraph-doc#527. Coordinate the documentation merge with this change.
• Doc - No Need

Conceptual overview

概念示意：在索引任务结束、无并发 schema 变更时逐个检查 Ready Server Pod 的可见关联索引，要求 CREATED，再执行可选业务断言；重试不会刷新索引缓存。

Conceptual diagram; not runtime test evidence. Live-cluster acceptance remains pending.

Source review PR: hugegraph#317

[bitflicker64]

Blocking: yes. Summary: Score 6/10. The per-Pod sweep, the JSON body quoting and the optional business assertions work as described, but the index-state check rejects only INVALID, while a Pod with a stale CREATING or REBUILDING index (status updates are not broadcast on hstore) fails indexed queries the same way and still passes. Evidence: read the full diff 4b77b7b..392faa9 (9 files) in a scratch worktree, with CachedSchemaTransactionV2 (getSchema, updateSchema, getAllSchema), SchemaTransactionV2.updateSchemaStatus/saveSchema, StandardHugeGraph.indexLabel(Id), HugeGraphAuthProxy.indexLabel(Id)/schema(), SchemaManager.getVertexLabels, IndexLabelRebuildJob, IndexLabelRemoveJob, OlapPropertyKeyClearJob and GraphIndexTransaction.validateIndexLabel/collectMatchedIndex. Ran python3 helm/test_helm_hook.py locally (5 pass, 1 skipped), and the skipped rendered-Groovy test passes with GROOVY_JAR set to groovy-4.0.25, the version the Server ships. The CI skip of that test is already raised in the existing thread on helm/test_helm_hook.py and is not repeated here. Latest-head checks pass or are skipped, including helm / lint-and-render and check-license. Not run: a live cluster or a real Server with a stale index label.

[imbajin]

Independent cross-check of the latest repair: 9.0/10 for this repair delta, not a whole-PR or live-cluster acceptance score.

Both previously reported issues are addressed: !index.status().ok() rejects all non-CREATED states while preserving ID-based cache lookup, and the rendered-query fixture can no longer silently skip. The workflow uses the root POM's Groovy version. I checked the actual current-head Helm job: all six hook fixtures executed and reported OK, without skips. This is inspected ASF CI evidence, not an independent local execution. Documentation now correctly requires waiting for index jobs to finish.

No new blocker identified in the reviewed delta and surrounding hook/fixtures. Real Server stale-cache behavior, live-cluster operation and business-query results remain outside these mocked fixtures; the stricter probe detects an unhealthy state and does not repair the underlying cache.

[bitflicker64]

Blocking: yes. Summary: Score 7/10. At 3290b46 both earlier points are fixed: the probe rejects every status other than CREATED, and CI now runs the rendered Groovy fixture instead of skipping it. One new problem remains: on hstore the probe's own graph.indexLabel(id) read caches an in-progress index status on Pods that are not running the index job, and that status never refreshes, so a helm test run during an index build fails for the whole deadline and leaves those Pods rejecting indexed queries afterwards. Evidence: read the full diff 4b77b7b..3290b46 (9 files) with CachedSchemaTransactionV2 (getSchema(type, id), updateSchema, addSchema, cache-expire note), SchemaTransactionV2 (addIndexLabel, updateSchemaStatus, saveSchema), IndexLabelBuilder.createWithTask, IndexLabelRebuildJob, StandardHugeGraph.indexLabel(Id)/openSchemaTransaction, HugeGraphAuthProxy.indexLabel(Id)/schema(), SchemaStatus.ok() and GraphIndexTransaction.validateIndexLabel. Locally on an archive of this head: python3 helm/test_helm_hook.py with GROOVY_JAR set to groovy-4.0.25 (the root POM version) runs 6 tests, all OK; helm unittest helm/hugegraph passes 296 tests in 36 suites. CI run 38680065791 at this head: helm / lint-and-render reports Ran 6 tests ... OK with no skips; check-license passes; other jobs are skipped by path filters. Not run: a live cluster or a real Server during an index build.

[bitflicker64]

Blocking: yes. Score: 6/10 (10 - 2 Important - 0.5 Minor = 7.5, capped at 6 because a finding is blocking). Summary: The index-state probe, per-Pod sweep, JSON quoting of server.testGremlin and the CI Groovy run all hold at 8f1be62. However, the master merge dropped the default alias fallback, so the upgrade command these docs give can make every Pod fail the hook. Evidence: read the full PR diff (9 files) and git diff 3290b466b..8f1be6238 restricted to the PR files (7b28f7b docs, plus the alias changes in the 8f1be62 merge). The rest of that range is master content from #3322/#3353 and was not reviewed. Traced CachedSchemaTransactionV2 (getSchema(type, id), getAllSchema, updateSchema, addSchema), StandardHugeGraph.indexLabel(Id), HugeGraphAuthProxy.indexLabel(Id)/vertexLabels() and SchemaManager.getVertexLabels. Locally: GROOVY_JAR=groovy-4.0.25.jar python3 helm/test_helm_hook.py ran 7 tests, all OK. helm unittest helm/hugegraph passed 307 tests in 36 suites. To emulate --reuse-values from 4b77b7b, I rendered test-connection.yaml with that values.yaml in place of the chart defaults: master renders "graph":"DEFAULT-hugegraph" and this head renders "graph":null. CI at this head: HugeGraph-Server CI 38771319689 is still pending (check-license queued). Not run: a live cluster or a real Server.

Earlier points from this account: the 3290b46 finding (the probe caches an in-progress index status on hstore and retries cannot clear it) is fixed in 7b28f7b. README and operations.md now require index jobs to finish first, warn that retries do not refresh the cached status, and drop the claim that the retry window lets index work settle. The 392faa9 points (reject every non-CREATED status, run the rendered Groovy fixture in CI) remain fixed at this head.