[PR #303] [MERGED] fix: clarify Ollama models without tool support #308

New Issue

2026-06-06T22:10:09-04:00

yindo commented

2026-06-06 22:10:09 -04:00

📋 Pull Request Information

Original PR: https://github.com/vxcontrol/pentagi/pull/303
Author: @mason5052
Created: 5/6/2026
Status: ✅ Merged
Merged: 5/21/2026
Merged by: @asdek

Base: feature/next-release ← Head: codex/issue-280-ollama-tool-support-validation

📝 Commits (2)

552eda8 fix: clarify Ollama models without tool support
73d5b83 fix: drop unverified ollama tags and broaden hint context

📊 Changes

3 files changed (+128 additions, -2 deletions)

View changed files

📝 backend/pkg/providers/helpers.go (+27 -0)
📝 backend/pkg/providers/helpers_test.go (+99 -0)
📝 backend/pkg/providers/providers.go (+2 -2)

📄 Description

Summary

Surface an actionable hint when an Ollama model that does not support tool/function calling is selected for a flow or assistant session, so users do not have to parse a five-wrap-deep "failed to determine tool call ID template" stack trace to figure out why provider initialization fails.

Problem

A user on an Ollama deployment of gemma3:27b-it-q4_K_M reports (issue #280) that the Provider/LLM test passes the basic completion checks but flow creation fails with:

failed to create flow worker: failed to get flow provider: failed to determine tool call ID template: failed to collect tool call ID samples: all sample collection attempts failed: failed to call LLM: 400 Bad Request: registry.ollama.ai/library/gemma3:27b-it-q4_K_M does not support tools

The underlying signal "does not support tools" is emitted by the Ollama API itself; PentAGI buries it five wraps deep, so the user is left guessing whether the issue is configuration, networking, or something internal to PentAGI.

Solution

Add an unexported helper wrapToolCallIDTemplateError in pkg/providers/helpers.go that detects the upstream does not support tools substring and prepends a one-sentence guidance message asking the user to select an Ollama model whose own metadata advertises tool/function calling support. PentAGI does not verify Ollama model capabilities against upstream metadata, so the hint deliberately avoids hard-coded model tags. All other errors keep the existing wording. The original error is preserved via %w so log spans, langfuse traces, and any future errors.Is/As callers continue to work.

Both call sites in pkg/providers/providers.go (NewFlowProvider, NewAssistantProvider) now route through the helper, and the helper's wording is provider-agnostic so it applies equally to flow and assistant sessions.

No schema, API, or DB changes. No new lifecycle state. No background work. The behavior change is the wording of one error string in one upstream-defined failure case.

User Impact

Users who pick an Ollama model without tool support get a clear, actionable error during flow / assistant creation instead of a deep stack trace.
Users on tool-capable models (Anthropic, OpenAI, Bedrock, and tool-capable Ollama tags) see no behavioral or message change.
No restart, migration, or configuration step required.

Test Plan

New table-driven test TestWrapToolCallIDTemplateError covers:
- nil error -> nil
- upstream "does not support tools" chain (matching the real five-wrap shape) -> actionable message + errors.Is round-trips to the original error
- generic non-tools error -> existing wrap text preserved, no new guidance appended
- regression check banning the previous concrete model tags (llama3.1, qwen2.5, mistral-nemo) and flow-only language (flow execution, flow creation)
go test ./pkg/providers -run TestWrapToolCallIDTemplateError -count=1 passes.
go test ./pkg/providers/... currently fails in pkg/providers/tester on TestTestProviderStreamingMode ("Expected non-zero latency for streaming test"). The same failure reproduces on upstream/main with no patch applied, so it appears pre-existing and environmental rather than introduced by this PR.

Closes #280

_{🔄 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/vxcontrol/pentagi/pull/303 **Author:** [@mason5052](https://github.com/mason5052) **Created:** 5/6/2026 **Status:** ✅ Merged **Merged:** 5/21/2026 **Merged by:** [@asdek](https://github.com/asdek) **Base:** `feature/next-release` ← **Head:** `codex/issue-280-ollama-tool-support-validation` --- ### 📝 Commits (2) - [`552eda8`](https://github.com/vxcontrol/pentagi/commit/552eda8746b428ea07435f049a7f096a3d417504) fix: clarify Ollama models without tool support - [`73d5b83`](https://github.com/vxcontrol/pentagi/commit/73d5b8366d923565c9d862182dca206f0387a2fb) fix: drop unverified ollama tags and broaden hint context ### 📊 Changes **3 files changed** (+128 additions, -2 deletions) <details> <summary>View changed files</summary> 📝 `backend/pkg/providers/helpers.go` (+27 -0) 📝 `backend/pkg/providers/helpers_test.go` (+99 -0) 📝 `backend/pkg/providers/providers.go` (+2 -2) </details> ### 📄 Description ## Summary Surface an actionable hint when an Ollama model that does not support tool/function calling is selected for a flow or assistant session, so users do not have to parse a five-wrap-deep "failed to determine tool call ID template" stack trace to figure out why provider initialization fails. ## Problem A user on an Ollama deployment of `gemma3:27b-it-q4_K_M` reports (issue #280) that the Provider/LLM test passes the basic completion checks but flow creation fails with: ``` failed to create flow worker: failed to get flow provider: failed to determine tool call ID template: failed to collect tool call ID samples: all sample collection attempts failed: failed to call LLM: 400 Bad Request: registry.ollama.ai/library/gemma3:27b-it-q4_K_M does not support tools ``` The underlying signal "does not support tools" is emitted by the Ollama API itself; PentAGI buries it five wraps deep, so the user is left guessing whether the issue is configuration, networking, or something internal to PentAGI. ## Solution Add an unexported helper `wrapToolCallIDTemplateError` in `pkg/providers/helpers.go` that detects the upstream `does not support tools` substring and prepends a one-sentence guidance message asking the user to select an Ollama model whose own metadata advertises tool/function calling support. PentAGI does not verify Ollama model capabilities against upstream metadata, so the hint deliberately avoids hard-coded model tags. All other errors keep the existing wording. The original error is preserved via `%w` so log spans, langfuse traces, and any future `errors.Is/As` callers continue to work. Both call sites in `pkg/providers/providers.go` (`NewFlowProvider`, `NewAssistantProvider`) now route through the helper, and the helper's wording is provider-agnostic so it applies equally to flow and assistant sessions. No schema, API, or DB changes. No new lifecycle state. No background work. The behavior change is the wording of one error string in one upstream-defined failure case. ## User Impact - Users who pick an Ollama model without tool support get a clear, actionable error during flow / assistant creation instead of a deep stack trace. - Users on tool-capable models (Anthropic, OpenAI, Bedrock, and tool-capable Ollama tags) see no behavioral or message change. - No restart, migration, or configuration step required. ## Test Plan - New table-driven test `TestWrapToolCallIDTemplateError` covers: - nil error -> nil - upstream "does not support tools" chain (matching the real five-wrap shape) -> actionable message + `errors.Is` round-trips to the original error - generic non-tools error -> existing wrap text preserved, no new guidance appended - regression check banning the previous concrete model tags (`llama3.1`, `qwen2.5`, `mistral-nemo`) and flow-only language (`flow execution`, `flow creation`) - `go test ./pkg/providers -run TestWrapToolCallIDTemplateError -count=1` passes. - `go test ./pkg/providers/...` currently fails in `pkg/providers/tester` on `TestTestProviderStreamingMode` ("Expected non-zero latency for streaming test"). The same failure reproduces on `upstream/main` with no patch applied, so it appears pre-existing and environmental rather than introduced by this PR. Closes #280 --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

yindo added the pull-request label 2026-06-06 22:10:09 -04:00

yindo closed this issue

2026-06-06 22:10:09 -04:00

yindo referenced this issue

2026-06-06 22:10:11 -04:00

[PR #308] [CLOSED] Add new provider configurations and update server ports #316

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: vxcontrol/pentagi#308