[BUG] Deploy on a plain (non-Git) internal stack returns 500 "Unexpected end of JSON input"

[framinosona]

Description

Calling the stack deploy endpoint for a plain, internal (non-Git) stack returns an HTML 500 error page with the message "Unexpected end of JSON input" — looks like the server tries to JSON.parse() an empty/absent request body without handling that case. The stack itself is unaffected (container keeps running as-is), the call just fails outright rather than deploying.

Reproduced via the strausmann/mcp-dockhand MCP integration, so I can't fully rule that layer out, but the response is a raw Dockhand-rendered 500 HTML error page (SvelteKit default error page), which points at the Dockhand backend itself throwing on an unhandled JSON parse.

Steps to reproduce

1. Create a plain internal stack (POST /api/stacks with a compose string referencing a pre-built image, e.g. image: ghcr.io/<user>/<image>:latest, plus envVars) and deploy it — this part works fine, container starts correctly with env vars applied.
2. Call the deploy endpoint again on that same stack (equivalent of clicking "Deploy" a second time, e.g. to pull a newer image tag) with no request body.
3. Get back:

   <title>Unexpected end of JSON input</title>
   ...
   <span class="status">500</span>
   <h1>Unexpected end of JSON input</h1>

4. The existing container is untouched (uptime doesn't reset) — the request fails before doing anything.

Logs

HTTP 500: Unexpected end of JSON input
(SvelteKit default error page, no additional server-side detail exposed via the response)

Dockhand version

1.0.27

Hawser version (if used)

N/A (direct socket connection)

Connection mode

socket

Please confirm the following

• I have already searched for relevant existing issues and discussions before opening this report — related: [Feature Request] Enable stack redeploy via API #981 (API stack redeploy)
• I have updated the title field above with a concise description.

[jotka]

hi @framinosona

Thanks for the detailed report — the 500 is a Dockhand bug, but the MCP layer also has a problem. There are actually two separate problems stacked here:

1. The 500 is ours — we'll fix it.
   POST /api/stacks/:name/deploy calls request.json() on the raw body without guarding for an empty one that result in rendering http500. Sending no body should just mean "deploy with defaults."

2. Fixing the 500 will not make the deploy work through strausmann/mcp-dockhand.
   Once the 500 is gone, the endpoint returns { jobId } and runs the deploy as a background job — the caller is expected to poll GET /api/jobs/{jobId} for the outcome. The MCP's deploy path takes the { jobId } and reports success without ever polling the job, so you'd be back to "returns success but I can't tell what happened" (this is the same underlying MCP issue as [BUG] Git-stack env-files API always 400s, and Deploy silently no-ops without the workaround #1270). We don't maintain that MCP, so that half needs to be filed against its repo.

If you're driving our API directly and want a synchronous result instead of the job flow, send Accept: application/json (without text/event-stream) on the deploy call — the endpoint then runs the deploy inline and returns the final result, no jobId, no polling.

So: we'll ship the 500 fix in dockhand 1.0.38. The deploy-observability piece is an MCP-client fix (poll the job, or send Accept: application/json) that belongs upstream. Leaving this open to track our part.