V2: Preserve explicit reasoning None across existing tool paths

Aperta
  • Qualcosa non va?
#1,846 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@paullizer ci sta già lavorando.

Dal 27/10/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

bug P1

Issue

Finish consistent reasoning-None handling across the existing GPT-5.6 tool-execution paths on paullizer-react-v2-ui. This is a request-shape consistency bug, not a claim that Sol, Luna, Terra, YAMCS, or database actions are universally broken: existing V2 agent deployments already execute those actions successfully.

V2's reasoning UI preserves explicit none, and budgeted agent execution applies the Azure tool restriction. However, the retained direct tabular/Semantic Kernel analysis path constructs function-tool settings without applying that policy. An actual SDK request-shape probe against the latest reviewed V2 source still omitted reasoning_effort while sending function tools.

Azure GPT-5.6 Chat Completions requires explicit reasoning_effort: "none" when function tools are present. Omitting the parameter is not equivalent to disabling reasoning; the provider's default can cause a 400. Main also strips explicit None in its older model behavior helper.

Steps to Reproduce

  1. Review V2 commit 11daaaa85c39d836347e2d3bc2d7512bfaadea38.
  2. Load the production execution_settings assignment in run_tabular_sk_analysis from application/single_app/route_backend_chats.py (line 13398 at that commit).
  3. Execute those settings through the real AzureChatCompletion/OpenAI SDK with a small function plugin and an httpx.MockTransport.
  4. Observe that the outgoing request contains tools but no reasoning_effort.

This reproduced the wire shape without a live Azure model call. It does not establish that every UI request enters this retained path or that this caused the customer's reported symptoms.

Expected Behavior

All applicable existing tool paths honor the selected model/provider/protocol policy and preserve explicit None. Supported combinations continue working without requiring users to understand the difference between omission and the literal none value.

Actual Behavior

Correct None handling exists in the frontend and budgeted agent wrapper, but it is not consistently applied at every tool-enabled model boundary. The direct tabular request can bypass it. Retries that merely remove the parameter do not resolve this Azure restriction.

Impact

Equivalent model/tool work can behave differently depending on whether it executes through a normal agent, a tabular helper, a fallback, or orchestration. Users can see errors, unnecessary retries, or slow analysis despite other actions working with the same model family.

Acceptance Criteria

  • Reuse the shared model/provider/protocol tool policy at every relevant existing tool-enabled invocation boundary, including retained tabular/fallback paths and applicable agent/orchestration execution.
  • Preserve explicit none through settings, adapters, SDK serialization, streaming, retries, and saved request metadata. Do not normalize it to omission.
  • Where the documented policy allows filling an unset effort with None, make the effective effort observable. Never silently replace an explicitly requested positive effort with None.
  • Give an actionable, safe configuration error for unsupported reasoning-plus-tools combinations rather than repeatedly dropping the parameter or changing API versions.
  • Preserve already-working Sol/Luna/Terra, GPT-5.1, YAMCS, SQL/database, and other existing action paths. Action plugins should not implement model-specific reasoning logic.
  • Add actual SDK wire-level regressions for each applicable GPT-5.6 catalog profile, with tools present/absent and omitted/None/positive effort, and cover affected active callers rather than only testing a standalone helper.
  • Update related documentation and apply the required application version bump when implementing.

Notes

Target: React V2 branch. Priority: P1. Assignee: @paullizer. Roadmap size: M.

Primary areas: model_endpoint_clients.py, functions_model_capabilities.py, functions_model_budget_runtime.py, functions_model_endpoint_runtime.py, semantic_kernel_loader.py, agent_logging_chat_completion.py, and route_backend_chats.py.

Broad reasoning-with-tools support belongs to #472. The GPT-6-specific restriction is tracked in #1606. This issue is the first, narrower compatibility fix and must not wait for or duplicate a full Responses migration.

Official contract: https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/reasoning#tool-calling-with-reasoning-models

No customer deployment changes or live performance claims are part of this reproduction.

Lingua principale
Python
Stelle
157
Fork
117
Merge medio
3h 6m
PR unite (30g)
219

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di microsoft/simplechat

Tutte le issue di microsoft/simplechat

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.