V2: Preserve explicit reasoning None across existing tool paths

オープン
  • 何か問題がありますか？
#1,846 コメント 0 件 リアクション 0 件 担当者 1 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@paullizer がすでに取り組んでいます。

2026年10月27日 から。

評価

この issue はまだ評価されていません。

説明

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.

主要言語
Python
スター
157
フォーク
117
平均マージ
3時間 6分
マージ済み PR（30日）
219

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

microsoft/simplechat のほかの issue

microsoft/simplechat の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。