[PR #15513] [CLOSED] openai: normalize colliding tool call indices in ToToolCalls #77477

Closed
opened 2026-05-05 10:08:31 -05:00 by GiteaMirror · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/ollama/ollama/pull/15513
Author: @mraleko
Created: 4/12/2026
Status: Closed

Base: mainHead: openai/normalize-tool-call-indices


📝 Commits (1)

  • c5a0fd0 openai: normalize colliding tool call indices in ToToolCalls

📊 Changes

2 files changed (+60 additions, -0 deletions)

View changed files

📝 openai/openai.go (+19 -0)
📝 openai/openai_test.go (+41 -0)

📄 Description

Summary

The legacy tools.Parser resets its internal counter (p.n) on each Add() call, which is invoked per streaming chunk in server/routes.go. When tool calls span multiple chunks, all arrive with Index=0, violating the OpenAI API requirement that each tool call have a distinct index.

Built-in parsers (cogito, gemma4, etc.) were fixed in #15467 to maintain a persistent callIndex across chunks. This applies the same safeguard at the OpenAI conversion layer.

Root cause

In routes.go:2501, toolParser.Add() is called per streaming chunk. The legacy parser's counter starts at 0 for each call, so tool calls from separate chunks all get Index=0. These are accumulated into a single []api.ToolCall slice that then gets passed to ToToolCalls.

Fix

In openai/openai.go:ToToolCalls, detect when all tool calls share the same index (always 0 in practice) and reassign them to 0..n sequentially before converting to the OpenAI format.

Changes

  • openai/openai.go: +19 lines — normalization logic in ToToolCalls
  • openai/openai_test.go: +41 lines — regression test TestToToolCallsNormalizesCollidingIndices

Validation

go test ./openai/... -run TestToToolCalls -v
# ✓ TestToToolCallsPreservesIDs      (existing test — distinct indices unchanged)
# ✓ TestToToolCallsNormalizesCollidingIndices (new test — collision fixed)

Fixes #15497


🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/ollama/ollama/pull/15513 **Author:** [@mraleko](https://github.com/mraleko) **Created:** 4/12/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `openai/normalize-tool-call-indices` --- ### 📝 Commits (1) - [`c5a0fd0`](https://github.com/ollama/ollama/commit/c5a0fd02f35889af09e5978a2a4e4767afda380e) openai: normalize colliding tool call indices in ToToolCalls ### 📊 Changes **2 files changed** (+60 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `openai/openai.go` (+19 -0) 📝 `openai/openai_test.go` (+41 -0) </details> ### 📄 Description ## Summary The legacy `tools.Parser` resets its internal counter (`p.n`) on each `Add()` call, which is invoked per streaming chunk in `server/routes.go`. When tool calls span multiple chunks, all arrive with `Index=0`, violating the OpenAI API requirement that each tool call have a distinct index. Built-in parsers (cogito, gemma4, etc.) were fixed in #15467 to maintain a persistent `callIndex` across chunks. This applies the same safeguard at the OpenAI conversion layer. ## Root cause In `routes.go:2501`, `toolParser.Add()` is called per streaming chunk. The legacy parser's counter starts at 0 for each call, so tool calls from separate chunks all get `Index=0`. These are accumulated into a single `[]api.ToolCall` slice that then gets passed to `ToToolCalls`. ## Fix In `openai/openai.go:ToToolCalls`, detect when all tool calls share the same index (always 0 in practice) and reassign them to `0..n` sequentially before converting to the OpenAI format. ## Changes - `openai/openai.go`: +19 lines — normalization logic in `ToToolCalls` - `openai/openai_test.go`: +41 lines — regression test `TestToToolCallsNormalizesCollidingIndices` ## Validation ```bash go test ./openai/... -run TestToToolCalls -v # ✓ TestToToolCallsPreservesIDs (existing test — distinct indices unchanged) # ✓ TestToToolCallsNormalizesCollidingIndices (new test — collision fixed) ``` Fixes #15497 --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the pull-request label 2026-05-05 10:08:31 -05:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#77477