Python: Fix OllamaChatClient passing unsupported kwargs to ollama.AsyncClient…

[max-montes]

Motivation and Context

Stop forwarding **kwargs from _inner_get_response() to ollama.AsyncClient.chat(). When the orchestration layer (e.g. HandoffBuilder) injects kwargs like allow_multiple_tool_calls=True, these were passed through unfiltered, causing a TypeError since ollama.AsyncClient.chat() does not accept them.

Description

This aligns with how other clients (e.g. OpenAIChatClient) handle kwargs — they only pass the prepared options_dict to the provider's API, not the raw **kwargs from the middleware chain.

Fixes #4402

Contribution Checklist

• [ X] The code builds clean without any errors or warnings
• [ X] The PR follows the Contribution Guidelines
• [X ] All unit tests pass, and I have added new tests where possible
• Is this a breaking change? If yes, add "[BREAKING]" prefix to the title of the PR.

[Copilot]

Pull request overview

Fixes the Ollama Python adapter to avoid forwarding orchestration/middleware-injected **kwargs into the Ollama SDK call (ollama.AsyncClient.chat()), preventing unexpected-keyword TypeErrors during workflows like handoffs.

Changes:

• Stop passing _inner_get_response() **kwargs through to ollama.AsyncClient.chat() (streaming and non-streaming paths).
• Add regression tests ensuring unsupported kwargs (e.g., allow_multiple_tool_calls) are not forwarded in either mode.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
python/packages/ollama/agent_framework_ollama/_chat_client.py	Removes forwarding of arbitrary **kwargs into AsyncClient.chat(), aligning behavior with other provider adapters.
python/packages/ollama/tests/test_ollama_chat_client.py	Adds regression coverage verifying unsupported kwargs are ignored for both streaming and non-streaming calls.

[markwallace-microsoft]

Python Test Coverage Report •

File	Stmts	Miss	Cover	Missing
TOTAL	22222	2757	87%

report-only-changed-files is enabled. No files were changed during this commit :)

Python Unit Test Overview

Tests	Skipped	Failures	Errors	Time
4720	247 💤	0 ❌	0 🔥	1m 20s ⏱️

[TaoChenOSU]

This looks like a duplicate of #4404. Please confirm and we can close this.

[max-montes]

This looks like a duplicate of #4404. Please confirm and we can close this.

Hi @TaoChenOSU — this PR was actually submitted first (#4403 at 22:33 UTC vs
#4404 at 22:41 UTC).

Beyond timing, the approaches differ:

• Python: fix(python): Filter unsupported kwargs in OllamaChatClient._inner_get_response #4404 uses a blocklist (_UNSUPPORTED_CHAT_KWARGS) to filter specific kwargs
  before chat() — but only covers the **kwargs path. New unsupported kwargs
  would need to be added to the set manually.
• This PR removes **kwargs forwarding to chat() entirely (it was never
  needed) AND adds allow_multiple_tool_calls to exclude_keys in
  _prepare_options(), which covers the options dict path too (e.g., from
  Agent.default_options or workflow cloning). This is a more complete fix with
  less code.

Happy to make any adjustments you'd like, but if you've chose to go with the other fix, I'll go ahead and close.

[moonbox3]

Automated Code Review

Reviewers: 3 | Confidence: 91%

✓ Correctness

The diff correctly fixes issue #4402 by stopping the forwarding of unsupported **kwargs to ollama.AsyncClient.chat() and adding allow_multiple_tool_calls to the set of keys excluded during option preparation. The three new tests cover the non-streaming kwargs path, the streaming kwargs path, and the options-dict path. The changes are focused, logically sound, and consistent with the existing codebase patterns.

✓ Security Reliability

This diff is a security improvement that removes the blind forwarding of **kwargs to the underlying Ollama AsyncClient.chat() call, preventing callers from injecting arbitrary, unvalidated parameters into the downstream API. The addition of 'allow_multiple_tool_calls' to exclude_keys and the accompanying regression tests are well-structured. No security or reliability issues are introduced by this change.

✓ Test Coverage

The diff removes forwarding of **kwargs to ollama.AsyncClient.chat() and adds allow_multiple_tool_calls to the exclude_keys set in _prepare_options. Three new tests cover the non-streaming kwargs path, streaming kwargs path, and options-dict path respectively. Coverage is solid for the specific regression case (issue #4402). Minor gaps: no test verifies that arbitrary/unknown kwargs (beyond allow_multiple_tool_calls) are also silently dropped, which would better document the broader behavioral change of removing **kwargs forwarding entirely. test_cmc_ignores_unsupported_options omits a result assertion but the intent is clear.

Suggestions

• Consider logging a debug-level warning when kwargs are silently dropped, so that users who accidentally pass an unsupported parameter get some feedback during development rather than silent no-op behavior.
• Consider logging a debug-level warning when kwargs are silently dropped so that callers can diagnose unexpected behaviour during development, rather than having parameters disappear without any signal.
• Consider adding a test that passes an arbitrary unknown kwarg (e.g., some_future_flag=True) to get_response and asserts it does not appear in the self.client.chat() call. This would document the broader behavioral change (all kwargs are now dropped, not just allow_multiple_tool_calls).
• In test_cmc_ignores_unsupported_options, consider adding assert result.text == "test" for consistency with the other two new tests, to confirm the response is still valid after filtering.

---

Automated review by moonbox3's agents

[moonbox3]

Reviewed and approved.

[eavanvalkenburg]

this is not a approach we want to take, since that parameter is already set to None in the OllamaChatOptions, people will get notified by their IDE if that is set, if that is being set by something like a workflow then we need to update that. The reason we don't want to hardcode filtering like this is because we want to not block future updates, let's say at some point Ollama does implement support for this parameter, then that will not be usable, because we filter it out, so we decided we would prefer to use the None above to notify the user beforehand that it is likely not right, and then we just let the API tell the user exactly what's wrong.