Tools override are not returned from the GET of the workload

[samuv]

Bug description

When editing a workload via POST with a tools_override parameter, the override is successfully applied and functional, but the GET endpoint for the workload always returns null for the tools_override field instead of returning the configured override values.

Steps to reproduce

1. Make a POST request to edit a workload with tools_override populated:

curl 'http://localhost:50088/api/v1beta/workloads/fetch-2/edit' \
  --data-raw '{"image":"ghcr.io/stackloklabs/gofetch/server:1.0.1","transport":"streamable-http","group":"default","target_port":25900,"cmd_arguments":[],"env_vars":{"FASTMCP_PORT":"25900","MCP_PORT":"25900","MCP_TRANSPORT":"streamable-http"},"secrets":[],"network_isolation":false,"volumes":[],"tools_override":{"fetch":{"name":"fetch_custom"}}}'

2. Verify the request returns 200 OK
3. Confirm the override is applied by using the playground and retrieving the tools list (the override should be visible there)
4. Make a GET request to retrieve the workload configuration:

curl 'http://localhost:50088/api/v1beta/workloads/fetch-2'

5. Observe the tools_override field in the response

Expected behavior

The GET endpoint should return the tools_override configuration that was set during the POST request:

{
  "tools_override": {
    "fetch": {
      "name": "fetch_custom"
    }
  }
}

Actual behavior

The GET endpoint returns "tools_override": null:

{
    "image": "ghcr.io/stackloklabs/gofetch/server:1.0.1",
    "host": "127.0.0.1",
    ...
    "tools": null,
    "tools_override": null,
    "group": "default",
    ...
}

Even though the override is actually applied and functioning (confirmed via playground tools list).

Environment (if relevant)

• Endpoint: /api/v1beta/workloads/{workload_id}
• OS/version: macOS Tahoe Version 26.0.1
• ToolHive version: v0.5.0

Additional context

The tools override is clearly being stored and applied correctly (evidenced by its appearance in the playground tools list), but the GET endpoint is not serializing/returning this field properly. This appears to be a serialization or response mapping issue in the GET endpoint rather than a storage problem.

[ChrisJBurns]

@claude Could you help with the investigation into what is happening?

[claude]

Claude finished @ChrisJBurns's task —— View job • claude/issue-2385-20251030-1527 • Create PR ➔

---

Investigation Complete

Root Cause

Found the issue in pkg/api/v1/workload_types.go. The runConfigToCreateRequest function converts a RunConfig to a createRequest for the GET API response, but it was missing the line to copy the ToolsOverride field.

The function correctly maps ToolsFilter but didn't map ToolsOverride, even though:

• The RunConfig struct has the field (pkg/runner/config.go:155)
• The updateRequest struct has the field (pkg/api/v1/workload_types.go:67)
• Both types are structurally compatible

This means the POST endpoint stores the override correctly in the RunConfig, but the GET endpoint returned null because the conversion function didn't copy it.

Fix Applied

Added conversion logic to map runConfig.ToolsOverride to the API's toolsOverride format in the runConfigToCreateRequest function. Also added a test case to verify the conversion works correctly.

Changes

• Modified pkg/api/v1/workload_types.go to include ToolsOverride conversion
• Added test case in pkg/api/v1/workloads_types_test.go to verify the fix

---

Branch |