fix(transport): drop invalid request_overrides keys instead of forwarding them - #61355
fix(transport): drop invalid request_overrides keys instead of forwarding them#61355Sahil-SS9 wants to merge 3 commits into
Conversation
|
@Sahil-SS9 so does it fix my #60821 or not, also thank you for looking into it |
…ding them request_overrides were merged directly into the top-level api_kwargs via dict.update(), so any stray key (e.g. a legacy top-level `system` from an old profile config) reached chat.completions.create() and raised `TypeError: Completions.create() got an unexpected keyword argument '<key>'` (hermes-agent#60821 / NousResearch#61030). Add a _VALID_TOP_LEVEL_API_KWARGS allowlist and a _safe_merge_request_overrides helper. Unknown keys are dropped with a debug log; extra_body/extra_headers are deep-merged into the existing values rather than clobbered. Applied to both the OpenAI and Gemini build_kwargs paths. Tests: tests/providers/test_profile_wiring.py::TestRequestOverridesInvalidKeys
8d6cb5f to
28b7b4e
Compare
teknium1
left a comment
There was a problem hiding this comment.
Thanks for adding defensive validation around the two Chat Completions override merge sites.
Problems
- The claimed #60821 root cause does not match the linked investigation: its reporter confirmed that correcting the third-party
skill-enforceplugin'srequest["system"]mutation resolved the crash. Please do not close #60821 from this PR without a separaterequest_overridesreproduction. tests/providers/test_profile_wiring.py:302covers only the ProviderProfile path, while this PR also replaces the legacy-path merge atagent/transports/chat_completions.py:538.agent/transports/codex.py:295-297still blindly updates Responses kwargs fromrequest_overrides. Either cover that sibling API-specific path or narrow the PR's stated scope to Chat Completions.
Suggested changes
- Reframe the issue linkage, add a legacy-path regression test, and clarify whether other transports are intentionally out of scope.
Automated hermes-sweeper review.
| class TestRequestOverridesInvalidKeys: | ||
| """Stray keys in request_overrides must NOT reach chat.completions.create().""" | ||
|
|
||
| def test_profile_path_drops_invalid_system_key(self, transport): |
There was a problem hiding this comment.
This exercises only the ProviderProfile path. _safe_merge_request_overrides() also replaces the legacy api_kwargs.update(overrides) path, so add a no-provider_profile invalid-key regression test to cover both changed call sites.
|
@rdxhemadri Thanks — no, this does not fix #60821. That was resolved by correcting the skill-enforce plugin mutation. This PR separately prevents invalid request_overrides keys from reaching Chat Completions. |
|
Hi @rdxhemadri, thanks for the question. This PR does not fix #60821 — #60821 was resolved by correcting the third-party |
Summary
request_overrideswere merged directly into top-levelapi_kwargs, so a stray key could reachchat.completions.create()and raise an unexpected-keywordTypeError.This fixes #61030: a legacy top-level
systemkey from an old profile config was forwarded as a kwarg. It does not fix or close #60821; that report was resolved by correcting the third-partyskill-enforceplugin'srequest["system"]mutation.Fix
extra_body/extra_headersoverrides.provider_profilelegacy paths.Scope
Chat Completions only. The Responses API remains out of scope because it has a different argument surface.
Verification
python -m pytest tests/providers/test_profile_wiring.py -q— 26 passed.Closes #61030