Skip to content

Fix issues with chat template application on responses requests #4173

Open
michalkulakowski wants to merge 2 commits intomainfrom
mkulakow/responses_fix_2
Open

Fix issues with chat template application on responses requests #4173
michalkulakowski wants to merge 2 commits intomainfrom
mkulakow/responses_fix_2

Conversation

@michalkulakowski
Copy link
Copy Markdown
Collaborator

🛠 Summary

JIRA/Issue if applicable.
Describe the changes.

🧪 Checklist

  • Unit tests added.
  • The documentation updated.
  • Change follows security best practices.
    ``

Copilot AI review requested due to automatic review settings April 30, 2026 12:48
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR targets improved OpenAI Responses API request handling in OVMS LLM serving so the existing Python/Jinja chat-template path can reliably consume Responses-format inputs (including tool-calling and reasoning-related items).

Changes:

  • Add debug logging before applying the Python/Jinja chat template.
  • Extend Responses input parsing to accept additional item/content shapes (reasoning summaries, tool-call items, missing/empty content, output_text).
  • Build a processedJson payload in chat/completions-style (messages + converted tools) for the Python/Jinja template path.

Reviewed changes

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

File Description
src/llm/py_jinja_template_processor.cpp Adds a debug log of the incoming request body before applying the chat template.
src/llm/apis/openai_responses.cpp Enhances Responses API parsing and constructs chat/completions-compatible processedJson including tool conversion and tool-call merging.

Comment on lines +126 to +130
// Handle function_call items (assistant tool use)
// For chatHistory (non-Python path), represent as an assistant message with empty content.
// The proper tool_calls structure is reconstructed in processedJson for the Python/Jinja path.
if (itemType == "function_call") {
request.chatHistory.push_back({});
return false;
}

SPDLOG_DEBUG("Before chat template: \n {}", requestBody);
Comment on lines 162 to +163
request.chatHistory.last()["role"] = roleIt->value.GetString();
if (!pendingReasoning.empty()) {
// can consume Responses API input without a separate code path.
// Build processedJson with a "messages" array in chat/completions format so that
// the Python Jinja template path can consume Responses API input without a separate code path.
// Handles reasoning (skipped), function_call (merged into assistant tool_calls), and
Comment on lines +309 to +316
auto inputArrIt = doc.FindMember("input");
if (inputArrIt != doc.MemberEnd() && inputArrIt->value.IsArray()) {
// Pending function_call items to be merged into the next assistant message
std::vector<const rapidjson::Value*> pendingFunctionCalls;
std::string pendingReasoningJson;

// Helper: flush pending function_calls as an assistant message with the given text content
auto flushPendingFunctionCalls = [&](const std::string& textContent) {
Comment on lines +486 to +489
// Responses API flat format — wrap under "function" key
Value convertedTool(kObjectType);
convertedTool.AddMember("type", Value("function", alloc), alloc);
Value funcObj(kObjectType);
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants