evalhub 0.3.0

Validate ext keys as {ns}/{name} on records, runs and facets: ext_key_invalid (0.3.0) (#49)

0.3.0: ext keys are checked as {ns}/{name}

Fixes #46. The schema crate and the served JSON Schema have always said that ext is keyed by namespace ({ns}/{name}), and nothing checked it: a record or a run with "ext": {"notes": {}} was accepted, stored and served.

Behaviour

• Every key of ext is validated with the same rule as a metric id, at the top level of a record or a run and inside each facet that carries an ext of its own (model, task, harness, generation, trial, grading, env).
• A violation is 422 with one ext_key_invalid per key, at /ext/{key} or /{facet}/ext/{key}. Values are still not looked into.
• Stored bodies are not rewritten. The rule applies to writes; a 0.2.0 body with an un-namespaced key keeps being read.

SDK (why 0.3.0)

• evalhub_schema::error::ErrorCode gains ExtKeyInvalid and is now #[non_exhaustive], as its doc already asked of clients ("treat an unknown code as a generic 422"). A match on it in another crate needs a fallback arm.
• schemas/error.json, the OpenAPI document and the web client's ErrorCode union are regenerated.

Deploy

Before fly deploy, run bash deploy/fly/ext-keys-check.sh (read-only) to list the stored keys a 0.2.0 hub accepted that 0.3.0 refuses on write, and record the result on #46. See docs/hosting.md, "Upgrading to 0.3.0".

Verification

cargo fmt --check, cargo clippy --workspace --all-targets -- -D warnings, cargo test -p evalhub-schema / -core / -query / -server (Docker), cargo insta test -p evalhub-server --test boot, just semver-check, just package, pnpm check / pnpm lint. Store tests not run (no Rust change there).

---

SDK crates: evalhub-schema evalhub-core evalhub-query
Image: ghcr.io/ynishi/evalhub:0.3.0