[BUG] Ollama ModelConfig options: integer coercion crashes on decimal strings, and boolean options only accept exact "true"

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

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

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

2026年10月19日 から。

  • #3279 @piyush182004 による — オープン

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
78/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
ollama, python
領域
ai, backend

調査の方向性

python/packages/kagent-adk/src/kagent/adk/types.pyから始め、Ollama SDKのOptions型を使って文字列値を処理する_convert_ollama_optionsを確認してください。この変換を対象とする既存のテストがあるか確認し、整数を表す小数文字列、一般的な真偽値の表記、変換できない値を対象とするテストを追加してください。これらの入力が説明どおりに処理され、エージェントの作成が失敗しなければ完了です。

索引モデルが issue の本文から書いたものです。

説明

📋 Prerequisites
  • I have searched the existing issues to avoid creating a duplicate
  • By submitting this issue, you agree to follow our Code of Conduct
  • I am using the latest version of the software
  • I have tried to clear cache/cookies or used incognito mode (if ui-related)
  • I can consistently reproduce this issue
🎯 Affected Service(s)

App Service

🚦 Impact/Severity

Blocker

🐛 Bug Description

_convert_ollama_options in python/packages/kagent-adk/src/kagent/adk/types.py converts the Ollama option values from the ModelConfig CRD (which arrive as strings) into the types the Ollama SDK expects. It has two bugs.

1. Integer options crash the agent build on a decimal string. int(value) is called directly, so an integer-typed option such as num_ctx: "2048.0" raises ValueError: invalid literal for int() with base 10: '2048.0'. This happens while the model is being constructed, so the entire agent fails to start rather than degrading gracefully.

2. Boolean options are only recognised as the exact string "true". The code uses value.lower() == "true", so common spellings such as "1", "yes" and "on" silently evaluate to False. Several Ollama options are booleans (numa, low_vram, f16_kv, use_mmap, use_mlock, logits_all, vocab_only, embedding_only, penalize_newline), so a user who enables one with low_vram: "1" gets it silently turned off with no warning.

🔄 Steps To Reproduce
  1. Configure an agent with an Ollama ModelConfig whose options contain an integer value written with a decimal point, e.g. num_ctx: "2048.0" (values arrive from the CRD as strings).
  2. Start the agent. The Python runtime calls _convert_ollama_options while building the model.
  3. Observe the agent fails to build with ValueError: invalid literal for int() with base 10: '2048.0'.

Minimal reproduction of the coercion function in isolation:

from kagent.adk.types import _convert_ollama_options

_convert_ollama_options({"num_ctx": "2048.0"})   # raises ValueError
_convert_ollama_options({"low_vram": "1"})        # -> {"low_vram": False}  (expected True)
_convert_ollama_options({"low_vram": "yes"})      # -> {"low_vram": False}  (expected True)
🤔 Expected Behavior
  • Integer options accept integral decimal strings such as "2048.0".
  • Boolean options accept the usual truthy/falsy spellings (1/0, true/false, yes/no, on/off), case-insensitively.
  • A value that genuinely cannot be converted is forwarded to the Ollama SDK (which reports it) instead of raising and failing agent construction.
📱 Actual Behavior
  • num_ctx: "2048.0" raises ValueError: invalid literal for int() with base 10: '2048.0' during model construction, so the whole agent fails to start.
  • low_vram: "1" and low_vram: "yes" silently become False, so the option is quietly ignored with no warning.

Confirmed end to end against a running Ollama: with options: {num_ctx: "2048.0", low_vram: "1"} the current coercion raises before Ollama is ever called; with tolerant coercion the options become {num_ctx: 2048, low_vram: True} and the model responds normally.

💻 Environment
  • Application version: latest main
  • Affected component: Python ADK runtime (kagent-adk)
  • File: python/packages/kagent-adk/src/kagent/adk/types.py (_convert_ollama_options)
  • OS: not OS-specific (pure Python coercion logic)
🔧 CLI Bug Report

No response

🔍 Additional Context

The affected function uses the Ollama SDK's Options model for type introspection, so the set of int/float/bool fields is taken from the SDK. The fix is a tolerant coercion: accept integral decimal strings for int fields, parse the common boolean spellings, and fall back to forwarding the raw value (with a warning) when a value cannot be converted, rather than raising.

No known workaround other than writing integer options without a decimal point and booleans as exactly "true".

📋 Logs

No response

📷 Screenshots

No response

🙋 Are you willing to contribute?
  • I am willing to submit a PR to fix this issue
主要言語
Go
スター
4.1k
フォーク
871
平均マージ
1日 6時間
マージ済み PR（30日）
170

環境構築

Codespaces で開く

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

はじめの一歩

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

kagent-dev/kagent のほかの issue

kagent-dev/kagent の issue をすべて見る

似ている issue

Go の issue をもっと見る

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

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