Opening Settings → Local Inference corrupts shared UI state; all data pages go empty
- Lenguaje dominante
- Rust
- Estrellas
- 54.2k
- Forks
- 6.2k
- Merge medio
- 3 d 4 h
- PR fusionados (30 d)
- 240
Descripción
**Describe the bug**
💡 Before filing, please check common issues:
https://goose-docs.ai/docs/troubleshooting
📦 To help us debug faster, attach your **diagnostics zip** if possible.
👉 How to capture it: https://goose-docs.ai/docs/troubleshooting/diagnostics-and-reporting/
A clear and concise description of what the bug is.
---
**To Reproduce**
Steps to reproduce the behavior:
1. Go to Settings - Local inference
2. Click on NOTHING
3. Than go to any other page (Scheduler, History, Skills, Receipts and so on)
4. See frozen UI without any data.
---
**Expected behavior**
All should work after I visit Local inference settings page.
---
**Screenshots**
My Histore page didn't load anything but there are a lot of dialogs in the left bar.
---
**Please provide the following information**
- MacOS (Intel) 14.7.4 (23H420)
- UI (Goose Desktop)
- 1.50.0 (latest)
- I disabled all plugins and extensions during debug this issue
- My own Llama.cpp server (on another computer with ubuntu) with moziAI-35B-A3B
---
**Additional context**
I discussed this problem a lot with `goose doctor` and tried all suggestions from it. It's final response:
```
# Bug: Opening Settings → Local Inference corrupts shared UI state; all data pages go empty
## Summary
Opening **Settings → Local Inference** in Goose Desktop leaves the entire app UI broken.
After opening that page and navigating away and back, every backend-backed page
(Receipts, Skills, Scheduler, History) renders empty. The backend (`goose serve`) stays
healthy and the on-disk session store is intact — this is a **frontend shared-state
corruption**, not a network, model-load, or data-loss issue.
## Environment
- App: Goose Desktop 1.49.0 (also reproduced on 1.50.0)
- OS: macOS 23.6.0 (x86_64)
- Active provider: `custom_llama` / model `moziai-35b-v3.7` (unchanged by the bug)
- Local models installed: **none** (see step 3 — reproducible with zero downloaded models)
## Reproduction steps
1. Start Goose (v1.49.0 or v1.50.0).
2. Confirm Receipts / Skills / Scheduler / History all load normally.
3. Open **Settings → Local Inference**. (Reproduces even with **zero** downloaded models —
no GGUF/llama-server is spawned.)
4. Switch to another settings page, then return.
## Observed behavior
- On the Local Inference page: after returning it shows "No available models" (even though
nothing was changed or deleted).
- Receipts, Skills, Scheduler, and History all become empty / fail to render.
- App appears "broken" — no further UI responses until restart.
## Verified NOT the cause (investigated)
- ❌ Not a network issue — HuggingFace endpoints reachable; no dependency on model download.
- ❌ Not a model-load issue — reproduces with **zero** downloaded models.
- ❌ Not a provider switch — `active_provider` stays `custom_llama`.
- ❌ Not backend/data loss — `goose serve` (PID alive, TLS ports up) and the on-disk
`Session Storage` leveldb remain intact; no model/corruption errors in logs.
## Root cause (provisional)
Opening Local Inference mutates a **shared frontend store** that every data page reads from.
The corruption persists across navigation, so all dependent pages render empty until the app
is restarted.
## Impact
High — the bug breaks core functionality (all data views) with a single page open and is
reproducible on both 1.49.0 and 1.50.0.
## Workaround
Restart Goose after opening Local Inference; avoid that page until fixed.
## Expected behavior
Opening Local Inference should not affect any other page's data rendering.
```
Do not begin implementation until the issue reaches **Ready** on the [Goose Issues board](https://github.com/orgs/aaif-goose/projects/1).
Guía de contribución
Línea de trabajo
El error está en la gestión del estado compartido del frontend, probablemente en un store que se corrompe cuando se abre la página de configuración de Local Inference. Empieza examinando el código del frontend encargado de la gestión del estado (por ejemplo, Zustand, Redux o un store personalizado) en torno a la lógica de configuración y obtención de datos. Revisa el componente que renderiza la página de Local Inference y comprueba qué mutaciones realiza. Reproduce el error localmente ejecutando la aplicación de escritorio y, después, revisa las solicitudes de red y los registros de la consola al navegar. La corrección debe aislar la mutación del estado para evitar la corrupción de los datos de otras páginas.
Escrito por el modelo de indexación a partir del texto del issue.
Evaluación
- Stack tecnológico
- javascript, typescript
- Área
- desktop, frontend
- Tipo de issue
- Error
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Estado de actividad
- Activo
- Claridad
- Bien especificado
- Aptitud para principiantes
- 65/100