Repository navigation
fix(typesafeai)!: a stored JevConfig with an unknown key fails to load - #3130
Merged
Merged
Conversation
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.
fix(typesafeai)!: a stored JevConfig with an unknown key fails to load
Description
A stored
JevConfigwith an unknown top-level key now fails to load, and the error names the key. Before, a typo such asprovderforproviderwas dropped silently. The config then loaded with no routing preferences, so the restrictions it meant to set (for exampledata_collection = "deny") were not sent.The fix is
#[serde(deny_unknown_fields)]onJevConfig. It has noflatten, aliases or skipped fields, so the attribute applies cleanly. #3127 did the same one level down, for keys insideprovider.What users see change
JevConfigwith an unknown top-level key (e.g.provder) fails to load withunknown fieldprovder, expected one oftoken,model,endpoint,provider``.token = "[redacted]"), a config with noprovider, a config withprovider(includingmax_priceand the forms feat(typesafeai): send OpenRouter provider preferences from JevConfig #3118's reload test covers), and a serializedJevConfigread back.JevConfigkey loads silentlyrig-typesafeaitests::a_misspelled_configuration_key_fails_to_load(fails on the test commit withOk(()), passes on the head)Changelog
JevConfigwith an unknown top-level key, such asprovidermisspelled asprovder, fails to load with an error naming the key, instead of loading without the restrictions it meant to set.Migration
A stored
JevConfigwith unknown keys now fails to load; remove or fix those keys.Type of change
Testing
cargo nextest run -p rig-typesafeai: all 26 tests pass on the head. The new test fails on the test commit.tomladded as a dev-dependency for that run only, not committed): the redacted token form, aprovidertable withmax_price, and a TOML round trip all load. A[provder]table fails naming the key. A JSON round trip also loads.cargo xtask verify --affected --base origin/main(on a build server) at the head.Checklist:
CHANGELOG.mdorMIGRATING.md(they are generated at release)Notes
Line deltas: production +1, tests +19.
Not verified: the committed test covers JSON only, because
rig-typesafeaihas no TOML dependency. TOML was checked once by hand as above. No live Jev call: this changes only loading, not what is sent.Follow-ups
provider.sortor a percentile threshold still loads silently (listed in fix(openrouter): a stored provider preference with an unknown key fails to load #3127).