Bug: update-endpoint silently drops GPU-pool exclusion entries in gpuIds, even when only unrelated fields are provided
Tool: update-endpoint
Description
The tool description states "Only provided fields change," implying a true partial update. In practice, calling update-endpoint with only an unrelated field set (e.g. imageName) also reset the endpoint's gpuIds/GPU-pool config, specifically dropping per-card exclusion entries (entries prefixed with -, e.g. AMPERE_48,ADA_48_PRO,-NVIDIA RTX A6000,-NVIDIA L40 → AMPERE_48,ADA_48_PRO).
This was only detectable after the fact via the RunPod dashboard's Releases tab diff — get-endpoint never surfaces the exclusion entries in its GPU pool response (it only returns the bare pool list), so there is no way to read-verify the full live gpuIds config before or after an update through the MCP tool alone.
Steps to reproduce
- Create/have a Serverless endpoint whose GPU pool config includes at least one
-<GPU type> exclusion entry (set via the RunPod dashboard or REST API).
- Call
update-endpoint with only an unrelated field, e.g. { "endpointId": "...", "imageName": "..." }.
- Check the endpoint's config in the RunPod dashboard's Releases tab.
Expected: Only imageName changes; gpuIds (including exclusion entries) is untouched.
Actual: imageName changes as expected, but the gpuIds exclusion entries are also dropped.
Suspected root cause
update-endpoint appears to reconstruct a full mutation payload (rather than sending a true partial patch), likely built from a prior get-endpoint-shaped read. Since that read shape doesn't include GPU-pool exclusion entries, any field not explicitly round-tripped gets reset to a default on write — not just the field(s) actually passed to the tool call.
Suggested fix
Either send a true partial patch (only literally the fields provided in the tool call), or have get-endpoint/the update path fully round-trip GPU-pool exclusion entries so they aren't silently lost.
Issue drafted with AI assistance (Claude Code) based on an observed production incident; reproduction steps above are generalized/minimal, not copied from the original project.
Bug:
update-endpointsilently drops GPU-pool exclusion entries ingpuIds, even when only unrelated fields are providedTool:
update-endpointDescription
The tool description states "Only provided fields change," implying a true partial update. In practice, calling
update-endpointwith only an unrelated field set (e.g.imageName) also reset the endpoint'sgpuIds/GPU-pool config, specifically dropping per-card exclusion entries (entries prefixed with-, e.g.AMPERE_48,ADA_48_PRO,-NVIDIA RTX A6000,-NVIDIA L40→AMPERE_48,ADA_48_PRO).This was only detectable after the fact via the RunPod dashboard's Releases tab diff —
get-endpointnever surfaces the exclusion entries in its GPU pool response (it only returns the bare pool list), so there is no way to read-verify the full livegpuIdsconfig before or after an update through the MCP tool alone.Steps to reproduce
-<GPU type>exclusion entry (set via the RunPod dashboard or REST API).update-endpointwith only an unrelated field, e.g.{ "endpointId": "...", "imageName": "..." }.Expected: Only
imageNamechanges;gpuIds(including exclusion entries) is untouched.Actual:
imageNamechanges as expected, but thegpuIdsexclusion entries are also dropped.Suspected root cause
update-endpointappears to reconstruct a full mutation payload (rather than sending a true partial patch), likely built from a priorget-endpoint-shaped read. Since that read shape doesn't include GPU-pool exclusion entries, any field not explicitly round-tripped gets reset to a default on write — not just the field(s) actually passed to the tool call.Suggested fix
Either send a true partial patch (only literally the fields provided in the tool call), or have
get-endpoint/the update path fully round-trip GPU-pool exclusion entries so they aren't silently lost.Issue drafted with AI assistance (Claude Code) based on an observed production incident; reproduction steps above are generalized/minimal, not copied from the original project.