fix(lib): preserve custom tool calls in parse_chat_completion

[PranavMishra28]

What

parse_chat_completion() — the helper behind client.chat.completions.parse() and streaming get_final_completion() — logs a warning and then drops every custom-type tool call:

elif tool_call.type == "custom":
    # warn user that custom tool calls are not callable here
    log.warning("Custom tool calls are not callable. Ignoring tool call: %s - %s", ...)
    # <-- never appended, so the call is discarded

So a supported GPT-5 custom tool call that the model emits disappears from the parsed result — message.tool_calls omits it, and for a custom-only turn it comes back None. The raw (unparsed) ChatCompletion carries the call correctly; only .parse() loses it.

The handling is also internally inconsistent: the trailing else branch already preserves any non-function tool call by appending it unchanged — only custom is special-cased to discard.

Fix

Append the custom tool call instead of dropping it, mirroring the else branch. Custom calls legitimately don't get parsed_arguments (there's no schema to parse their free-form input against), so they're surfaced as-is. The now-inaccurate "Ignoring tool call" warning — which fired on every custom call in normal use — is removed.

Tests

tests/lib/chat/test_parse_custom_tool_calls.py (pure unit tests, no mock server / live API): a custom-only message and a mixed function+custom message. Both fail on next before this change (the custom call is dropped / tool_calls is None) and pass after. The existing tests/lib/chat/test_completions.py suite still passes; ruff and pyright --strict are clean on the changed files.

Scope / honest limitation

ParsedChatCompletionMessage.tool_calls is a generated type narrowed to list[ParsedFunctionToolCall]. With this fix a custom call round-trips through attribute access and its own model_dump(), but its custom payload is still dropped when the entire completion is serialized (pydantic serializes the list by its declared element type) — the same limitation the existing else branch already has for non-function calls. Fully fixing serialization would require widening the generated tool_calls type, which is out of scope for a lib/-only change; happy to coordinate if you'd prefer that path.

Rebased onto main and retargeted there (this PR originally targeted next; main is where external fixes land — 36 of the last 40 merges, and next currently points at the same commit).

Developed with Claude Code; reviewed and tested by Pranav before marking ready for review.

[PranavMishra28]

leaving a note since dropping custom calls looks intentional at a glance — but the else branch just below already appends any non-function tool call as-is, so custom was actually the only tool-call type being discarded here. this just makes it consistent. custom calls have no schema to parse args against, so they pass through unchanged (no parsed_arguments), same as the else path.

[PranavMishra28]

@seratch would appreciate your eyes on this when you get a chance. small one: parse_chat_completion() drops GPT-5 custom tool calls on a custom-only turn (the raw completion keeps them, only .parse() loses them). the fix just appends the custom call instead of discarding it, mirroring how the else branch already preserves non-function calls. tests included, targeted at next. happy to adjust if you'd rather handle it a different way.

[PranavMishra28]

@apcha-oai @jbeckwith-oai small correction on my end: this originally targeted next, which was wrong. 36 of the last 40 merges go to main, and next currently points at the same commit (cbdc98b). I have retargeted it and rebased onto main, so it is now a single commit, +78/-7 across one source file and one new test file.

The bug: parse_chat_completion logs a warning and then drops every custom-type tool call, so a custom tool call the model made disappears from .parse() output (tool_calls comes back None for a custom-only turn). The else branch immediately below already preserves non-function tool calls unchanged, so custom was the only type being discarded. This appends it the same way.

One thing worth deciding before you spend review time: ParsedChatCompletionMessage.tool_calls is a generated type narrowed to list[ParsedFunctionToolCall], so with this change a custom call survives attribute access and its own model_dump(), but its custom payload is still dropped when the whole completion is serialized. Fixing that properly means widening the generated type, which I cannot do from here.

So: do you want this lib-only fix as-is, or should it be handled upstream in the Stainless spec instead? Happy to close this if it is the latter.