Skip to content

ONTAP-MCP panic, proccess exits instead of returning errors #95

@dmaryuma-ops

Description

@dmaryuma-ops

*Environment:

ghcr.io/netapp/ontap-mcp:latest (v1.0.0)
Host: macOS Apple Silicon (arm64), running amd64 image via Colima/QEMU
MCP Client: GitHub Copilot in VS Code
ONTAP: 9.18.1

Bug 1 — panic: strings.Builder.Grow: negative count in ontap_get
Trigger: Calling ontap_get with a path that results in a malformed URL (e.g. /protocols/cifs/services with a filter on an SVM that has no CIFS server).
Stack trace:
panic: strings.Builder.Grow: negative count strings/builder.go:78 net/url.(*URL).String (url.go:810) github.com/carlmjohnson/requests.(*urlBuilder).URL (core_url.go:89) github.com/netapp/ontap-mcp/rest.(*Client).GenericGet (client.go:423) github.com/netapp/ontap-mcp/server.(*App).OntapGet (server.go:447)

Bug 2 — fatal error: SIGSEGV during JSON marshaling of tool parameters
Trigger: Receiving a tool call where a map[string]string parameter field is nil — the JSON encoder dereferences a nil map via reflection.

Stack trace:
fatal error: fault addr=0x61657222202020 reflect.maplen (map.go:292) encoding/json.isEmptyValue (encode.go:355) encoding/json.structEncoder.encode (encode.go:735) → triggered during tool parameter marshaling in the MCP SDK handler

Common Root Cause
Neither panic is wrapped in a recover(). Any unhandled Go panic propagates to the top level and kills the entire HTTP server process. The MCP client sees TypeError: terminated / fetch failed.

Suggested fix: Add a recover() middleware at the HTTP handler level (or per tool handler) to catch panics and return a proper MCP error response instead of crashing.

Workaround

docker run --restart unless-stopped ...

Daniel

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions