SebastianGruza opened a new issue, #772: URL: https://github.com/apache/hugegraph-toolchain/issues/772
Parent: #748, checklist items "Define the compatibility matrix and shared test fixtures" and "Publish baseline benchmarks against the current implementation". ## Scope 1. **Client contract fixtures.** A language-neutral set of JSON files, one per REST call: method, path, the headers that matter for the contract, request body, expected status and response shape (required fields, types, constant values). The first version covers the "minimal client" from #748: `/versions`, auth (basic and token), schema (property key, vertex label, edge label, index label), graph (vertex, edge, batch, batch update with strategies), gremlin. Versioned per server API version. The source of truth is the behaviour of the Java client against the server commit pinned in CI: the fixtures are *recorded* from the Java client (an interceptor in `RestClient` that writes the request and the response), not written by hand, so they cannot drift from the code. 2. **Runners.** Java: a test in `hugegraph-client` that replays every fixture through the client and checks that the request sent and the parsed response match the file. Go: the same set through `hugegraph-client-go`; endpoints without an implementation are reported as `unsupported`, not as failures. The output is a Java/Go parity matrix generated in CI (markdown in the job artifacts), the first version of the "compatibility matrix" from the checklist. 3. **Loader baseline benchmark.** A script and a deterministic data generator (parameterised size; CI profile: 100k vertices / 500k edges, full profile: 5M / 25M), loading through `hugegraph-loader` on rocksdb and on hstore, metrics: rows/s, p50/p99 batch time, loader RSS and heap, startup time, time to resume after a `SIGKILL` half-way (resumability), retry count. Results as markdown in the repo with hardware, server and loader versions, plus raw logs. First publication from my 3-node k3s cluster (Helm chart from hugegraph/hugegraph#221) and from the CI runner for the small profile. ## Non-goals - No Rust code in this issue; no change to the behaviour of the Java client or the loader (the fixtures describe what is there, including the rough edges; Java/Go divergences become separate issues). - No traversers, auth management, graph spaces or Vermeer in the first version; they follow once the format holds. - No server benchmarks; the loader is measured as a client. ## Compatibility The fixtures are test data, not an API; they live in `hugegraph-dist/contract/` (or a separate `hugegraph-contract` module, to be decided in the PR) and are consumed by tests in the existing `client-ci` and `client-go-ci` jobs, against the same pinned server commit. A new server API version is a new fixture directory; old ones stay. ## Acceptance criteria - The Java runner passes in `client-ci` on all three Java versions; the Go runner passes in `client-go-ci` with the parity matrix in the artifacts. - Re-recording the fixtures from the same server commit yields identical files (determinism: ids and timestamps normalised). - The benchmark script reproduces the CI-profile result with a single command; the published full-profile numbers come with logs and configuration. - `docs/contract-tests.md`: how to record, how to add an endpoint, how to plug in a new language. ## PR plan | # | content | when | |---|---|---| | 1 | fixture format, recorder in the Java client, Java runner, 12 endpoints (versions, auth, 4 schema, vertex, edge, batch, batch update, gremlin), doc | this week | | 2 | Go runner, parity matrix in CI, issues for the divergences | +1 week | | 3 | data generator and loader benchmark script, CI profile in `loader-ci`, numbers from the cluster | +2 weeks | | 4 (optional) | minimal Rust: transport + `/versions` + fixture runner as proof of a third language; only if 1–3 land and there is interest | to be decided | -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
