code-yeongyu / code-yeongyu/senpi

Ollama provider: catalog fetch failure leaves models-store.json empty forever — /model lists no Ollama models and no error is surfaced

Open
#839 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
TypeScript
Stars
429
Forks
98
Avg merge
5h 3m
Merged PRs (30d)
526

Description

### Summary

For the built-in `ollama` provider (Ollama Cloud), the model catalog is discovered dynamically via `fetchModels` (`GET https://ollama.com/api/tags` + per-model `/api/show`) and persisted to `~/.omo/models-store.json` (or the agent dir equivalent). If the first network refresh never completes successfully, the store stays `{}` permanently. From then on:

- `/model` shows no Ollama models at all (the provider's model list is empty).
- Model selectors like `ollama/glm-5.2` fail validation (`is not a valid or known model selector` in fallback-chain validation) because the registry has zero models for the provider.
- No error or warning tells the user that the catalog fetch failed or never ran. The failure is silent and self-perpetuating: startup restores from the (empty) store and, depending on the network policy path, never retries a network refresh.

### Environment

- senpi: `@code-yeongyu/senpi@2026.8.11-4` (via `omo-ai@5.0.0-0.beta.6`, OMO native profile)
- pi-ai: `@earendil-works/pi-ai@2026.8.11-4`
- OS: Windows 11 (win32 x64)
- Auth: `ollama` API key present in `auth.json`, and `OLLAMA_API_KEY` set as a User environment variable
- Ollama Cloud API verified reachable with the same key: `GET https://ollama.com/api/tags` returns 18 models including `glm-5.2`

### Steps to reproduce

1. Have a valid Ollama Cloud API key configured.
2. Ensure `models-store.json` is empty (`{}`) — e.g. after a first run where the catalog refresh was aborted or the network path was not taken.
3. Start a new session.
4. Open `/model` → no Ollama models listed.
5. Observe `models-store.json` is still `{}`; no warning is printed about the missing catalog.

### Expected behavior

One of:

- Startup performs (or schedules) one network catalog refresh for configured providers whose store entry is missing/empty, or
- A failed/never-run catalog fetch surfaces a visible warning (e.g. "Ollama catalog unavailable: /model will not list Ollama models"), and/or
- A manual command (`/models refresh` or similar) re-fetches and persists the catalog.

### Actual behavior

The empty store is treated as a valid cached catalog; the provider appears configured (auth OK) but exposes zero models; fallback-chain validation emits misleading "not a valid or known model selector" warnings for perfectly valid selectors like `ollama/glm-5.2`.

### Evidence

Relevant code paths (as shipped in `@code-yeongyu/senpi@2026.8.11-4`):

- `dist/core/model-runtime.js` line ~78: `modelNetworkEnabled = envValue("OFFLINE") === undefined && options.allowModelNetwork === true`; line ~81: `refreshFromNetwork = runtime.modelNetworkEnabled && options.allowModelNetwork === true` — startup network refresh depends on both flags, and the failure/abort path records nothing user-visible.
- `dist/core/models-store.js` (`FileModelsStore`): plain JSON map `{ [providerId]: { models, checkedAt } }` — stays `{}` if no successful refresh ever writes it.
- `node_modules/@earendil-works/pi-ai/dist/providers/ollama.js`: `fetchOllamaModels` requires per-model `/api/show`; abort/throw paths keep previous in-memory models but write nothing when `refreshed.length === 0` or the signal is aborted.
- `dist/core/retry-fallback/validate.js`: validates selectors against `registry.getAll()`; with an empty Ollama catalog, `ollama/glm-5.2` warns as "not a valid or known model selector".

Manual verification that the catalog itself is fine:

```
GET https://ollama.com/api/tags (Bearer $OLLAMA_API_KEY)
→ 18 models: qwen3.5:397b, minimax-m3, deepseek-v4-pro, ..., glm-5.2, glm-5.1, ...
```

### Workaround (user-side)

Populate `models-store.json` manually with the entry shape senpi writes (`{ "ollama": { "models": [...], "checkedAt": } }`), using `toOllamaModel`'s field layout (`id`, `name`, `api: "openai-completions"`, `provider: "ollama"`, `baseUrl: "https://ollama.com/v1"`, `reasoning`, `input`, zeroed `cost`, `contextWindow`, `maxTokens: 16384`, `compat`). After this, `/model` lists Ollama models and `ollama/glm-5.2` validates cleanly.

### Suggested fix direction

- Treat a missing/empty store entry for a configured provider as "needs refresh" and attempt one network refresh at startup regardless of the cached path, and/or persist fetch errors so the TUI can warn once.
- Optionally include provider-level fetch diagnostics in the fallback-chain validation warning (e.g. "provider `ollama` has no models — catalog may not have been fetched").

Contributor guide

Open the contributing guide

Research direction

Start with dist/core/model-runtime.js and dist/core/models-store.js to trace how an empty Ollama catalog is restored and refreshed, then inspect node_modules/@earendil-works/pi-ai/dist/providers/ollama.js and dist/core/retry-fallback/validate.js. Reproduce with an empty models-store.json, verify that a configured Ollama provider retries or surfaces a warning, and confirm that /model lists fetched models and ollama/glm-5.2 validates.

Written by the indexing model from the issue text.

Assessment

Tech stack
ollama, typescript
Domain
backend, cli
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.