fix: llama-stack function tool serialization for Gemini compatibility

[dprince]

What does this PR do?

llama-stack's Responses API to Chat Completions conversion in streaming.py leaks a "type" field into the function tool dict via model_dump(). The OpenAI Chat Completions FunctionDefinition schema only allows name, description, parameters, and strict — not type. OpenAI silently ignores the extra field, but Gemini's OpenAI-compatible endpoint strictly validates and rejects it with:
"Unknown name 'type' at 'tools[N].function': Cannot find field."

Fix: exclude type from serialization in streaming.py:
function=input_tool.model_dump(exclude={"type"})

Test Plan

unit tests included

[meta-cla]

Hi @dprince!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[meta-cla]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

[leseb]

Can you leave an inline comment explaining why we exclude "type"? Something like:

# Exclude "type" from the function dict — it belongs on the outer
# ChatCompletionToolParam, not inside the FunctionDefinition.
# OpenAI silently ignores the extra field, but stricter endpoints
# (e.g. Gemini) reject it.

This will save future contributors from wondering why the exclude is there.

[dprince]

Can you leave an inline comment explaining why we exclude "type"? Something like:

# Exclude "type" from the function dict — it belongs on the outer
# ChatCompletionToolParam, not inside the FunctionDefinition.
# OpenAI silently ignores the extra field, but stricter endpoints
# (e.g. Gemini) reject it.

This will save future contributors from wondering why the exclude is there.

Done, in the latest rebase. Thanks

[mattf]

the original code is 1 step too clever using model_dump instead of adding strict to make_openai_tool

also, responses tools have further evolved and allow a defer_loading field, do we need to add that to the exclude too?

two suggestions -

• directly translate the fields we need and don't use model_dump
• file an issue about supporting defer_loading, aka tool search

[dprince]

I implemented the switch to make_openai_tool in the latest push

[derekhiggins]

From https://github.com/llamastack/llama-stack/actions/runs/23007399456/job/66809064669?pr=5082#step:6:2736

         RuntimeError: Recording not found for request hash:                                                            
         5cf1d08147f27ac9aa5bea505ac059a8d0419953c76d84d5611fadce99c8ce68                                               
         Model: gpt-4o | Request: POST https://api.openai.com/v1/v1/chat/completions                                    

It used to be possible to run scripts/github/schedule-record-workflow.sh to generate recordings in CI, but I haven't tried it lately, does anybody know if this is it still possible?

[derekhiggins]

@mattf, this is the PR I was talking about (although I see you already here), thanks

[mattf]

this is the PR I was talking about (although I see you already here), thanks

@derekhiggins i've posted gpt recordings and a few ollama, but my current ollama deployment is incomplete

[mergify]

This pull request has merge conflicts that must be resolved before it can be merged. @dprince please rebase it. https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[dprince]

@mattf thanks for the recordings. I attempted to rebase those as there were conflicts.

[mergify]

This pull request has merge conflicts that must be resolved before it can be merged. @dprince please rebase it. https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[mergify]

This pull request has merge conflicts that must be resolved before it can be merged. @dprince please rebase it. https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[leseb]

@dprince sorry for the lack of attention here, we have a job to do recordings on behalf of users, can you rebase? thanks

[mergify]

This pull request has merge conflicts that must be resolved before it can be merged. @dprince please rebase it. https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[github-actions]

✅ Recordings committed successfully

Recordings from the integration tests have been committed to this PR.

View commit workflow