fix: resolve GraphQL schema mismatches for Unraid 7.2.x API#12
fix: resolve GraphQL schema mismatches for Unraid 7.2.x API#12udhaya10 wants to merge 3 commits intojmagar:mainfrom
Conversation
- info: fix versions query from flat fields to nested core/packages structure - info: remove deprecated apps field from Info type - info: fix os.codepage -> os.codename - info: fix metrics cpu.used -> cpu.percentTotal - info: fix server query versions.unraid -> versions.core.unraid - health: fix comprehensive check versions.unraid -> versions.core.unraid - health: fix result processing to use nested versions.core.unraid path - docker: remove logs query (field does not exist on Docker type in current API) - docker: replace logs action with helpful error directing to web UI or SSH Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- network: query uses vars fields (network top-level field removed in API) - connect: query uses vars fields (connect top-level field removed in API) - services: remove state field (only name exists on Service type) - servers: remove description/ip/port fields (only id/name/status valid) - flash: remove guid/size fields (only id/product/vendor valid) - result handler: update network and connect to read from vars response key All 16 info queries now verified working against Unraid 7.2.3 API. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
📝 WalkthroughWalkthroughUpdates GraphQL queries and tool behaviors to align with Unraid 7.2 schema changes, including deprecating GraphQL logs access, restructuring version query paths, simplifying query fields, and adding LICENSE file to Docker image. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Tip Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
unraid_mcp/tools/info.py (1)
416-417: 🧹 Nitpick | 🔵 Trivial
serveraction returns the entire raw GraphQL response without processing.All other actions either extract a specific key or apply processing. Returning raw
datahere exposes the GraphQL response structure directly (with top-level keysinfo,array,online), which is inconsistent with the pattern of the other actions. This also means any future GraphQL response shape changes will leak directly to callers.Consider extracting and assembling a processed summary similar to other actions.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@unraid_mcp/tools/info.py` around lines 416 - 417, The branch that handles action == "server" currently returns the raw GraphQL response variable data; change it to assemble and return a processed summary (matching the pattern used by other actions) by extracting the top-level keys from data (e.g., data.get("info"), data.get("array"), data.get("online")) and build a normalized dict with only the needed fields (such as summary/info, items/array, status/online) instead of returning data directly; update the code in the action == "server" block to validate/normalize those keys and return that processed dict.unraid_mcp/tools/docker.py (1)
108-108:⚠️ Potential issue | 🔴 CriticalBug:
logsaction is unreachable — blocked byALL_ACTIONSvalidation.
"logs"was removed fromQUERIESbutALL_ACTIONSis derived fromset(QUERIES) | set(MUTATIONS) | {"restart"}, so"logs"is no longer inALL_ACTIONS. The guard at Line 250 (if action not in ALL_ACTIONS) will reject"logs"with a generic "Invalid action" error before the informativeToolErrorat Lines 284-288 is ever reached.🐛 Proposed fix
-ALL_ACTIONS = set(QUERIES) | set(MUTATIONS) | {"restart"} +ALL_ACTIONS = set(QUERIES) | set(MUTATIONS) | {"restart", "logs"}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@unraid_mcp/tools/docker.py` at line 108, The constant ALL_ACTIONS currently omits "logs" (ALL_ACTIONS = set(QUERIES) | set(MUTATIONS) | {"restart"}), which causes the generic guard that checks if action not in ALL_ACTIONS to reject "logs" before the more specific ToolError handling runs; fix by including "logs" in ALL_ACTIONS (or explicitly allowing action == "logs" in the initial guard) so the "logs" action passes validation and reaches the intended ToolError path; update the ALL_ACTIONS definition (or the guard that references ALL_ACTIONS) to include "logs" so the behavior around action validation and ToolError (lines around the current guard and the ToolError at lines ~284-288) is preserved.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@unraid_mcp/tools/info.py`:
- Around line 50-55: The three GraphQL query strings network, connect, and
variables all query the same root field vars which can be confusing when they
share the same response key in dict_actions; add short inline comments above
each query string (e.g., "# Network-related vars", "# Connect-related vars", "#
General variables") to clarify which subset of vars each query is intended to
return and why they share the same response key, and update the dict_actions
entries (dict_actions keys for network, connect, variables) if necessary to
reference those commented queries for maintainability.
---
Outside diff comments:
In `@unraid_mcp/tools/docker.py`:
- Line 108: The constant ALL_ACTIONS currently omits "logs" (ALL_ACTIONS =
set(QUERIES) | set(MUTATIONS) | {"restart"}), which causes the generic guard
that checks if action not in ALL_ACTIONS to reject "logs" before the more
specific ToolError handling runs; fix by including "logs" in ALL_ACTIONS (or
explicitly allowing action == "logs" in the initial guard) so the "logs" action
passes validation and reaches the intended ToolError path; update the
ALL_ACTIONS definition (or the guard that references ALL_ACTIONS) to include
"logs" so the behavior around action validation and ToolError (lines around the
current guard and the ToolError at lines ~284-288) is preserved.
In `@unraid_mcp/tools/info.py`:
- Around line 416-417: The branch that handles action == "server" currently
returns the raw GraphQL response variable data; change it to assemble and return
a processed summary (matching the pattern used by other actions) by extracting
the top-level keys from data (e.g., data.get("info"), data.get("array"),
data.get("online")) and build a normalized dict with only the needed fields
(such as summary/info, items/array, status/online) instead of returning data
directly; update the code in the action == "server" block to validate/normalize
those keys and return that processed dict.
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
1 issue found across 4 files
Prompt for AI agents (all issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="unraid_mcp/tools/docker.py">
<violation number="1" location="unraid_mcp/tools/docker.py:284">
P2: `logs` is no longer included in `ALL_ACTIONS`, so the early validation rejects `action="logs"` and the new ToolError guidance in the logs branch is unreachable. This effectively disables the `logs` action while it remains in `DOCKER_ACTIONS`.</violation>
</file>
Since this is your first cubic review, here's how it works:
- cubic automatically reviews your code and comments on bugs and improvements
- Teach cubic by replying to its comments. cubic learns from your replies and gets better over time
- Add one-off context when rerunning by tagging
@cubic-dev-aiwith guidance or docs links (includingllms.txt) - Ask questions if you need clarification on any suggestion
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
Related PRs & Conflict Heads-upJust did a sweep of the other open PRs to flag any overlap: PR #3 (partial overlap)fix: update GraphQL queries for Unraid API v4.21.0+ by @abra5umente fixes the same 3 fields (
This PR is a superset of PR #3 for 7.2.x. If PR #3 is merged first, this PR will still apply cleanly on top (different fields/lines), though a rebase would tidy things up. PR #11 (potential merge conflict)refactor: comprehensive code review fixes by @jmagar touches nearly every file in the repo (+2093/-719). If #11 merges before this PR, there will likely be conflicts in PRs #5, #6, #7, #8 — no overlapFocus on error handling, tests, infra, and new tooling — no schema query changes. |
Introspected the live Unraid GraphQL API and fixed all queries that referenced nonexistent fields or types. Removed Docker mutations and queries that the API does not expose (pause, unpause, remove, update, logs, network_details, port_conflicts, check_updates). Unavailable actions now return clear error messages instead of crashing. Based on community PR jmagar#12 findings, verified against actual schema.
|
Thanks for the PR and the thorough testing against 7.2.3! Both review comments addressed: cubic-dev-ai (P2 bug): Fixed — added coderabbitai (clarity): Fixed — added inline comments to Changes pushed to |
- Add 'logs' to _DOCKER_SUBACTIONS so the validation guard passes through to the informative ToolError rather than a generic 'Invalid action' (P1) - Add inline comments to _SYSTEM_QUERIES explaining that 'network' and 'variables' share the vars root field but fetch different subfields (P3) - Process system/server response into a structured summary dict instead of returning raw GraphQL data directly (P3)
2 participants
Summary
Fixes all GraphQL schema mismatches introduced in Unraid 7.2.x that caused multiple MCP tools to fail with field validation errors. Verified and tested against a live Unraid 7.2.3 installation.
Closes #9
Changes
unraid_mcp/tools/info.pyGetSystemInfo(overview)os { ... codepage ... }codepage(field removed in 7.2 API)GetSystemInfo(overview)versions { kernel openssl ... unraid }versions { id core { unraid api kernel } packages { openssl node npm pm2 git nginx php docker } }GetSystemInfo(overview)apps { installed started }GetNetworkConfig(network)network { id accessUrls { ... } }vars { id useSsl port portssl localTld }GetConnectSettings(connect)connect { status sandbox flashGuid }vars { id flashGuid flashProduct flashVendor }GetMetrics(metrics)cpu { used }cpu { percentTotal }GetServices(services)services { name state }services { name }(stateremoved)GetServer(server)versions { unraid }versions { core { unraid } }GetServers(servers)servers { id name status description ip port }servers { id name status }GetFlash(flash)flash { id guid product vendor size }flash { id product vendor }"network": "network""network": "vars""connect": "connect""connect": "vars"unraid_mcp/tools/health.pyComprehensiveHealthCheckqueryversions { unraid }versions { core { unraid } }.get("versions", {}).get("unraid").get("versions", {}).get("core", {}).get("unraid")unraid_mcp/tools/docker.pylogsGraphQL query —docker.logsfield does not exist in the current APIToolErrordirecting users to the Unraid web UI or SSH (docker logs <id>)Test Environment
http://<unraid-host>:6970/mcp)Tool-by-Tool Test Results
unraid_info— 16 actions tested against Unraid 7.2.3overviewCannot query field "codepage","apps", flatversionsfieldsarraynetworkCannot query field "network"registrationconnectCannot query field "connect"variablesmetricsCannot query field "used" on CpuMetricspercentTotalreturnedservicesCannot query field "state" on ServicedisplayconfigonlineownerserverCannot query field "unraid" on InfoVersionsserversserverstypeflashguid,sizefields removedsettingsunraid_health— all 3 actionscheckCannot query field "unraid" on InfoVersions→ returnedunhealthyhealthy, includes version, uptime, array state, docker containerstest_connectiondiagnoseunraid_array— all 5 actionsparity_statusunraid_docker— 14 actions (logs removed)listdetailsstart/stop/restartlogsdocker.logsfield does not existunraid_storage,unraid_vm,unraid_notifications,unraid_rclone,unraid_users,unraid_keysAll actions verified working before and after (no schema changes needed).
Root Cause
The Unraid 7.2.x API removed or restructured several GraphQL fields:
info.os.codepageremovedinfo.appsremovedinfo.versionschanged from a flat scalar map to a nested object (core,packages)networktop-level field removed (replaced byvars)connecttop-level field removed (replaced byvars)metrics.cpu.usedrenamed tometrics.cpu.percentTotalservices.stateremovedservers.description/ip/portremovedflash.guid/sizeremoveddocker.logsremoved entirely🤖 Tested with Claude Code against a live Unraid 7.2.3 instance
Summary by cubic
Fixes GraphQL schema mismatches for Unraid 7.2.x to restore all MCP tools and stop field validation errors. Verified against Unraid 7.2.3.
Written for commit 8f38815. Summary will update on new commits.
Summary by CodeRabbit
Bug Fixes
Chores