Repository navigation
Validate ext keys as {ns}/{name} on records, runs and facets: ext_key_invalid (0.3.0) - #49
Merged
Merged
Conversation
…_invalid (0.3.0)
The schema crate has always documented `ext` as a map keyed by namespace,
and the served JSON Schema says the same, but nothing checked it: a record
or a run with `"ext": {"notes": {}}` was accepted, stored and served (#46).
The semantic pass now runs every key of `ext` through the same `{ns}/{name}`
rule as metric ids, 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), and reports one `ext_key_invalid` (422) per key at
`/ext/{key}` or `/{facet}/ext/{key}`. Values are still not looked into.
`ErrorCode` gains the variant and becomes `#[non_exhaustive]`, which its doc
already asked of clients ("treat an unknown code as a generic 422"); the
variant is why this is 0.3.0. `schemas/error.json`, the OpenAPI snapshot and
the web client's `ErrorCode` union are regenerated.
Stored bodies are not rewritten; the rule applies to writes.
`deploy/fly/ext-keys-check.sh` lists the stored keys a 0.2.0 hub accepted
that 0.3.0 would refuse, to run before the deploy (docs/hosting.md).
Closes #46
Signed-off-by: Yutaka Nishimura <ytk.nishimura@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
0.3.0:
extkeys are checked as{ns}/{name}Fixes #46. The schema crate and the served JSON Schema have always said that
extis keyed by namespace ({ns}/{name}), and nothing checked it: a record or a run with"ext": {"notes": {}}was accepted, stored and served.Behaviour
extis 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 anextof its own (model,task,harness,generation,trial,grading,env).422with oneext_key_invalidper key, at/ext/{key}or/{facet}/ext/{key}. Values are still not looked into.SDK (why 0.3.0)
evalhub_schema::error::ErrorCodegainsExtKeyInvalidand is now#[non_exhaustive], as its doc already asked of clients ("treat an unknown code as a generic 422"). Amatchon it in another crate needs a fallback arm.schemas/error.json, the OpenAPI document and the web client'sErrorCodeunion are regenerated.Deploy
Before
fly deploy, runbash 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. Seedocs/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).