fix: exclude gpt-5.4-mini from reasoning_effort in /v1/chat/completions#76326
fix: exclude gpt-5.4-mini from reasoning_effort in /v1/chat/completions#76326chinar-amrutkar wants to merge 4 commits into
Conversation
Distinct WhatsApp contacts were colliding on the same :main session key,
causing shared .jsonl files and interleaved model context.
- Added dmScopeOverride to ResolveAgentRouteInput so callers can force a
specific dmScope regardless of the global config setting
- WhatsApp now passes dmScopeOverride: "per-channel-peer" when resolving
inbound routes, producing session keys of the form
agent:{agentId}:whatsapp:direct:{peerId}
- Added regression test verifying distinct peerId values produce distinct
route.sessionKey values
Closes openclaw#76263
|
Codex review: needs changes before merge. Summary Reproducibility: yes. The linked OpenAI bug is source-reproducible because current main resolves Next step before merge Security Review findings
Review detailsBest possible solution: Keep the endpoint-scoped OpenAI fix, preserve documented WhatsApp account-level DM isolation, and either split the unrelated WhatsApp work or cover it with matching tests/docs/changelog before merge. Do we have a high-confidence way to reproduce the issue? Yes. The linked OpenAI bug is source-reproducible because current main resolves Is this the best way to solve the issue? No. The OpenAI API-scoped resolver direction is maintainable, but the branch must not collapse multi-account WhatsApp DMs and still needs the required OpenAI changelog entry. Full review comments:
Overall correctness: patch is incorrect Acceptance criteria:
What I checked:
Likely related people:
Remaining risk / open question:
Codex review notes: model gpt-5.5, reasoning high; reviewed against 85e4ec1fb1ac. |
c8873df to
f9e67ae
Compare
When using per-channel-peer dmScope, updateWhatsAppMainLastRoute now records the last-route against the per-contact sessionKey instead of skipping it. This ensures deliveryContext metadata is persisted for later session deliveries. Added test: "records last-route for per-contact session when using scoped dmScope"
… guard The pin guard (pinnedMainDmRecipient) applies only to main session updates. Per-contact sessions should always record their last-route since they are independent of the main session pin state. Updated test to use pinnedMainDmRecipient that differs from dmRouteTarget to verify the per-contact session is updated even when not the pinned owner.
Only suppress reasoning_effort for gpt-5.4-mini in chat/completions API. Responses API paths retain GPT_52 reasoning efforts since the model supports reasoning in that context. Fixes openclaw#76176
365780d to
14f6f57
Compare
|
Closing this bundled PR in favor of one PR per issue:
Thanks @chinar-amrutkar for the original fixes; the replacement PRs keep the issues split and preserve the WhatsApp multi-account isolation case. |
Summary
reasoning_effortin/v1/chat/completions, but OpenClaw was sending it, causing 400 errorsgpt-5.4-miniinresolveOpenAISupportedReasoningEffortsto return[], placed before the broadergpt-5.1andgpt-5patternsreasoning_effortsupportChange Type
Scope
Linked Issue/PR
Root Cause
gpt-5.4-minimatches/^gpt-5(?:-|$)/uand gets assignedGPT_5_REASONING_EFFORTS, but the model only supportsreasoning_effortin the Responses API, not/v1/chat/completionsgpt-5.4-minifrom chat completions reasoning effortUser-visible / Behavior Changes
Security Impact
Compatibility / Migration