<go-sdk> Return failed tool result for empty tool name to avoid dangling tool_calls

[lonegunmanb]

Summary

When a model emits an OpenAI-compatible tool call with a missing/empty tool name, the current SDK/CLI path appears to surface it as a session-level error instead of returning a structured failed tool result for the pending tool call. This can leave the provider-visible conversation history with an assistant.tool_calls entry that is not followed by a corresponding tool message, causing the next request in the same session to be rejected by OpenAI-compatible providers.

Observed behavior

In a long-running session using an OpenAI-compatible provider, the model emitted a malformed tool call whose function/tool name was empty. The host surfaced:

Tool name is missing

The application caught that session/stream error and attempted to continue the same session by sending a corrective nudge. The next provider request then failed with:

400 An assistant message with 'tool_calls' must be followed by tool messages responding to each 'tool_call_id'. (insufficient tool messages following tool_calls message)

This suggests the malformed assistant tool call had already become part of the session history, but no structured tool result message was appended for its tool_call_id.

Why this is hard for SDK consumers to repair

At the application layer we only receive a session error message such as Tool name is missing. We do not have a reliable way to append a provider-visible structured tool result message with the original tool_call_id, nor can we safely edit/rewind the SDK-managed conversation history.

Sending a normal follow-up/nudge prompt is not equivalent to appending a role=tool message. OpenAI-compatible providers validate the message structure before generating the next response, so a textual nudge cannot repair a dangling assistant.tool_calls entry.

Requested change

If the tool call has a valid tool_call_id but the tool name is missing/empty, please consider returning a structured failed tool result for that tool call instead of surfacing a session-level/JSON-RPC error that leaves history unrepaired.

For example, conceptually:

if req.ToolCallID != "" && req.ToolName == "" {
    return &toolCallResponseV2{Result: ToolResult{
        TextResultForLLM: "Tool call failed: tool name is missing or incorrect. Retry using one of the registered tool names.",
        ResultType:       "failure",
        Error:            "tool name is missing or incorrect",
        ToolTelemetry:    map[string]any{},
    }}, nil
}

The important behavior is that the session/provider history gets a proper failed tool result associated with the pending tool_call_id, allowing the model to self-correct within the same session and preserving long-running context.

Edge cases

If the tool_call_id is also missing, then a standards-compliant tool message cannot be constructed. In that case, the SDK/CLI may need a different recovery path, such as discarding/rolling back the invalid assistant tool-call message before the next provider request, or exposing enough structured diagnostic data for clients to decide whether to reset the session.

Expected behavior

• Empty/missing tool name with a valid tool_call_id should produce a structured failed tool result, not poison the session history.
• The next request in the same session should not fail provider-side with dangling assistant.tool_calls / missing tool messages.
• SDK consumers should not need to rebuild the session and lose long-running context just to recover from one malformed tool call.

Environment

• SDK: Go SDK path in github.com/github/copilot-sdk/go API surface
• Provider mode: OpenAI-compatible completions/chat tool-call protocol
• Provider observed: DeepSeek OpenAI-compatible API

[lonegunmanb]

Clarification after re-checking the SDK dispatch path:

The non-empty-but-unsupported tool name case already appears to return a structured failed ToolResult:

handler, ok := session.getToolHandler(req.ToolName)
if !ok {
    return &toolCallResponseV2{Result: ToolResult{
        TextResultForLLM: fmt.Sprintf("Tool '%s' is not supported by this client instance.", req.ToolName),
        ResultType:       "failure",
        Error:            fmt.Sprintf("tool '%s' not supported", req.ToolName),
        ToolTelemetry:    map[string]any{},
    }}, nil
}

So the requested behavior is more specifically: treat ToolName == "" with a valid ToolCallID the same way as an unsupported tool name, i.e. return a structured failed ToolResult associated with that pending tool call instead of returning a JSON-RPC/session-level invalid payload error.

Conceptually:

if req.SessionID == "" || req.ToolCallID == "" {
    return nil, &jsonrpc2.Error{Code: -32602, Message: "invalid tool call payload"}
}
if req.ToolName == "" {
    return &toolCallResponseV2{Result: ToolResult{
        TextResultForLLM: "Tool call failed: tool name is missing or incorrect. Retry using one of the registered tool names.",
        ResultType:       "failure",
        Error:            "tool name is missing or incorrect",
        ToolTelemetry:    map[string]any{},
    }}, nil
}

If ToolCallID is missing too, then a standards-compliant tool result cannot be associated with the assistant tool call, so that remains a separate recovery problem.

[roji]

If the tool_call_id is also missing, then a standards-compliant tool message cannot be constructed. In that case, the SDK/CLI may need a different recovery path, such as discarding/rolling back the invalid assistant tool-call message before the next provider request, or exposing enough structured diagnostic data for clients to decide whether to reset the session.

I'm no expert, but as far as I know, the tool_call_id is generated deterministically by the provider, not by the model; in other words, a missing ID would represent a real bug in the provider. In contrast, since tool names are generated (non-deterministically) by the model, they can be missing/empty in normal operations. If that's all true, then we should indeed ensure proper error handling and correct recovery for missing names, but it's reasonable to treat missing IDs as a contract violation representing an upstream bug, and not build in elaborate recovery mechanisms.