ci: pin the measurement_id hash with golden vectors in-repo#8687
Conversation
scripts/_measurement_id.py computes the primary key of every fact row in the benchmarks-website Postgres, so its output is frozen forever: drift would break ON CONFLICT (measurement_id) idempotency against rows already in production. Until now the only automated pin was a Rust test in the benchmarks-website repo's server/ crate, which is being deleted as part of the v3 teardown. Bring the golden vectors (generated by that original Rust source of truth, now a frozen artifact that must never be regenerated) into this repo, add a pytest asserting the Python port reproduces all 63 vectors, and run it as a lightweight CI job. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
Merging this PR will not alter performance
|
| Mode | Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|---|
| ❌ | Simulation | chunked_varbinview_opt_canonical_into[(100, 100)] |
305.2 µs | 340.4 µs | -10.34% |
| ⚡ | Simulation | chunked_varbinview_canonical_into[(1000, 10)] |
190.9 µs | 154.6 µs | +23.46% |
Tip
Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.
Comparing ct/measurement-id-golden-pin (907e60a) with develop (1ba1515)
Footnotes
-
4 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩
Its vectors include deliberate Unicode edge cases (JSON-escaped, so "café" reads as the token "caf"), and the file's bytes must never change, so it is excluded rather than "fixed". Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
The v3 generation was fully decommissioned on 2026-07-08: monorepo PR vortex-data/vortex#8683 removed the v3 ingest steps and made the v4 Postgres ingest required, and the EC2 host, its S3 backups, and its IAM/SG resources were deleted. This removes the code that served it: server/ (the axum ingest/read server), migrate/ (the v2->v3->v4 migrator, whose backfill job finished on 2026-07-07), ops/ (the host deploy scripts), the Cargo workspace, the Rust CI workflow, and the v3 runbooks. The measurement_id hash contract the Rust server owned moves to the monorepo: the golden vectors and a Python pin test now live there (vortex-data/vortex#8687), so scripts/measurement_id_golden.json is deleted here and web/lib/schema-version.test.ts drops its server/src/schema.rs anchor, making web/lib/schema-version.ts the in-repo source of truth. Docs are updated to describe the single v4 ingest path and to mark the v3 sections as historical. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
|
@claude review |
|
Claude review automation is disabled for pull requests that modify Why:
Ask a human reviewer to inspect workflow changes directly. |
|
Can you make the PR desc a bit more concise (and maybe high level)? |
measurement_id hash with golden vectors in-repo
The v3 generation was fully decommissioned on 2026-07-08: monorepo PR vortex-data/vortex#8683 removed the v3 ingest steps and made the v4 Postgres ingest required, and the EC2 host, its S3 backups, and its IAM/SG resources were deleted. This removes the code that served it: server/ (the axum ingest/read server), migrate/ (the v2->v3->v4 migrator, whose backfill job finished on 2026-07-07), ops/ (the host deploy scripts), the Cargo workspace, the Rust CI workflow, and the v3 runbooks. The measurement_id hash contract the Rust server owned moves to the monorepo: the golden vectors and a Python pin test now live there (vortex-data/vortex#8687), so scripts/measurement_id_golden.json is deleted here and web/lib/schema-version.test.ts drops its server/src/schema.rs anchor, making web/lib/schema-version.ts the in-repo source of truth. Docs are updated to describe the single v4 ingest path and to mark the v3 sections as historical. Signed-off-by: Connor Tsui <connor.tsui20@gmail.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Summary
Right now, there is no way for us to ensure that our
measurement_idkey that we generate in CI matches the ones that we have on thebenchmarks-websitecode.This adds a bunch of "golden" hashes so that we can immediately see if something changes here that would break the contract with the benchmarks website server.
Merge this before vortex-data/benchmarks-website#7 so the hash is never unpinned.