Repository navigation
Take toolregistry 0.19 and toolregistry-server 0.7 - #193
Merged
Merged
Conversation
Both released today. 0.19 carries the union fix we have been waiting on (Oaklight/ToolRegistry#269, our #165), and the pair changes three things that reach clients. The union fix is real: a heterogeneous union now renders as `anyOf` instead of silently dropping branches. The floor moves to 0.19.0 so an older registry cannot be resolved, because the schema repair that used to cover for it is no longer shaped the same way. What we serve for `lat_spec` still is not upstream's rendering, though. The annotation is `tuple | float | list[Any] | None`, and `tuple` and `list` both render as `array`, so 0.19 emits the array branch twice with untyped items: anyOf: [ {array, items:{}}, {number}, {array, items:{}} ] A duplicated branch is noise in a payload we measure, and untyped items say less than we know. `_type_untyped_unions` now replaces that rendering rather than only filling an absence, and serves the canonical form: anyOf: [ {number}, {array, items:{number}} ] The core tool specification goes 36271 -> 36143 bytes as a result, so no budget moves. Two behaviour changes in toolregistry-server 0.7: - An unknown tool name is now a JSON-RPC -32602 rather than a `CallToolResult` with `isError`. That is the correct reading -- `isError` is for a tool that ran and failed, and an unknown name means nothing ran -- so the test asserts the new contract instead of pinning the old one. - 0.7 infers annotations of its own, and marked `manage_session` and `resume_workflow` `readOnlyHint=True`. Neither is read-only: `manage_session` resets session state and clears artifacts, `resume_workflow` runs pending steps. Nine tools we had deliberately left unrated came back carrying hints, and a client reading `readOnlyHint` may auto-approve on the strength of it. Our shim deferred to any annotation already present, which handed the decision to whoever guessed first. It now asserts our rating where we have one and clears the field where we have not. Absence is the honest answer for a tool nobody rated; an inferred hint is a claim no one checked, and a wrong safe-to-run claim is the one failure direction that costs a user something. `TestUpstreamInferenceDoesNotOverruleUs` pins both halves, and names `manage_session` and `resume_workflow` specifically so a future release making the same guess fails here rather than in a client. 1540 passed, 1 skipped, 44 deselected, 1 xfailed. Does not close #165: the checklist there also asks to drop the workaround entirely, and the duplicate-branch rendering above means it still earns its place. Updated there with what 0.19 did and did not fix.
7 tasks
The lockfile audit went red on this branch while it was green on main three days ago, with the same pillow 12.3.0 pinned in both. Nothing here pulled it in: 44 advisories against 12.3.0 were published in between, 5 of them Critical, all fixed in 13.0.0. pillow arrives transitively through bokeh and matplotlib under uxarray's viz extra, so there is nothing of ours to re-point. `uv lock --upgrade-package pillow` moves that one package and nothing else. Carried on this branch rather than in its own PR because the audit is a required check and this branch cannot merge while it is red. The plotting tests pass on 13.0.0, which is the part of pillow this server actually uses.
Clearing pillow exposed two more the scanner had not reached: PYSEC-2026-4320 against certifi 2026.7.22, which is a 9.1 Critical, and four against virtualenv 21.14.7 including a 7.8 High. Both published in the same window as the pillow set. certifi is the trust store every outbound HTTPS call in this server uses -- Globus Compute submission, Globus transfers, remote dataset reads -- so a Critical there is not a transitive detail. virtualenv arrives through the dev toolchain. Each moves to its first fixed release and nothing else resolves differently.
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.
Both released today.
toolregistry0.19.0 carries the union fix we have beenwaiting on (Oaklight/ToolRegistry#269, our #165), and the pair changes three
things that reach clients.
The union fix is real
A heterogeneous union now renders as
anyOfinstead of silently droppingbranches. The floor moves to 0.19.0 / 0.7.0.
But we still do not serve upstream's rendering
lat_specis annotatedtuple | float | list[Any] | None.tupleandlistboth render as
array, so 0.19 emits the array branch twice, with untypeditems:
A duplicated branch is noise in a payload we measure, and untyped items say
less than we know.
_type_untyped_unionsnow replaces that rendering ratherthan only filling an absence:
Core tool specification 36271 → 36143 bytes, so no budget moves.
Two behaviour changes in toolregistry-server 0.7
Unknown tool is now a protocol error.
-32602instead of aCallToolResultwithisError. This is the correct reading —isErroris fora tool that ran and failed; an unknown name means nothing ran — so the test
asserts the new contract instead of pinning the old one.
0.7 infers its own annotations, and got two wrong. It marked
manage_sessionandresume_workflowasreadOnlyHint=True. Neither isread-only:
manage_sessionresume_workflowNine tools we had deliberately left unrated came back carrying hints. A client
reading
readOnlyHintmay auto-approve on the strength of it.Our shim deferred to any annotation already present, which handed the decision
to whoever guessed first. It now asserts our rating where we have one and
clears the field where we have not. Absence is the honest answer for a tool
nobody rated; an inferred hint is a claim no one checked, and a wrong
safe-to-run claim is the one failure direction that costs a user something.
TestUpstreamInferenceDoesNotOverruleUspins both halves and names those twotools specifically, so a future release making the same guess fails here rather
than in a client. Reverting the fix fails 3 tests (verified).
Verification
1540 passed, 1 skipped, 44 deselected, 1 xfailedDoes not close #165
That checklist also asks to remove the workaround entirely. The
duplicate-branch rendering above means it still earns its place — I have
updated the issue with what 0.19 did and did not fix.