Remove lat_spec schema workaround after ToolRegistry releases union fix
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 65/100
Research direction
The workaround is in registry._trim_wire_schema, involving _UNTYPED_UNION_SCHEMAS and _type_untyped_unions(). First, check the upstream issue Oaklight/ToolRegistry#269 to see if a fix is released. Then, upgrade the toolregistry dependency, update uv.lock, and test that run_analysis and plot_dataset serve the lat_spec schema correctly without the local repair. Finally, remove the workaround code and run the regression tests to ensure the wire contract is maintained.
Written by the indexing model from the issue text.
Description
Summary
PR #164 added a downstream workaround in registry._trim_wire_schema because ToolRegistry 0.18.1 drops branches from heterogeneous union schemas. Keep that workaround until the upstream defect is fixed and released, then adopt the fixed ToolRegistry release and remove our compatibility code.
Upstream tracking issue: Oaklight/ToolRegistry#269
Current workaround
Commit 14ed993 adds _UNTYPED_UNION_SCHEMAS / _type_untyped_unions() so the served lat_spec schema advertises both accepted wire types:
numberarray<number>
The workaround is deliberately a no-op if ToolRegistry begins emitting type or anyOf itself.
When upstream releases a fix
- Upgrade the minimum
toolregistryversion to the first release containing Oaklight/ToolRegistry#269. - Refresh
uv.lockand package metadata as needed. - Confirm
run_analysisandplot_datasetservelat_specasnumber | array<number>without local schema repair. - Confirm a JSON array such as
[-60, 60]passes throughexecute_tool_callsvalidation. - Remove
_UNTYPED_UNION_SCHEMAS,_type_untyped_unions(), and its call from_trim_wire_schema. - Retain or adapt the regression tests so the wire contract remains pinned to real registry execution.
- Re-measure and lower the schema payload budgets if removing the workaround changes their size.
Blocking condition
Do not remove the workaround merely because the upstream issue or PR is merged. Wait until a ToolRegistry release containing the fix is available and the end-to-end tests pass against that released version.
- Dominant language
- Python
- Stars
- 4
- Forks
- 2
- Avg merge
- 1h 43m
- Merged PRs (30d)
- 24
Getting set up
- Ships a Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from UXARRAY/uxarray-mcp-server
-
Difficulty 3/5 Half a day Newbie friendliness 48/100
UXARRAY/uxarray-mcp-server#171 ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
UXARRAY/uxarray-mcp-server#89 ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
UXARRAY/uxarray-mcp-server#67 ·
Maintainers usually reply within 1 day
All issues in UXARRAY/uxarray-mcp-server
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
SwiftKickMobile/skai#84 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 82/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
jxxghp/MoviePilot#7070 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
flop-labs/technocore-chat#997 ·
Maintainers usually reply within 1 day
-
tunneld on Windows: Wi-Fi devices are not discovered because uvicorn runs on a ProactorEventLoopOpen
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
doronz88/pymobiledevice3#2051 ·
Maintainers usually reply within 1 day