Evandro Fonseca Junior
77c57c3d45
- Check process_running and ready state before making inference request
- Emit descriptive error messages for each failure scenario
- Handle local vs remote connection modes appropriately
- Validation score: 100 (was 0)
Result: {"status":"keep","validation_score":100,"response_time_ms":500}
31 lines
1.5 KiB
Markdown
31 lines
1.5 KiB
Markdown
---
|
|
plan name: fix-model-swap
|
|
plan description: Fix model swap race condition
|
|
plan status: active
|
|
---
|
|
|
|
## Idea
|
|
Corrigir a race condition onde o modelo selecionado é sobrescrito pelo refresh automático durante uma troca de modelo.
|
|
|
|
**Problema identificado:**
|
|
1. Usuário seleciona modelo B no frontend
|
|
2. `swapModel()` é chamado para trocar no backend
|
|
3. O backend leva tempo para trocar (para API, reinicia com novo modelo)
|
|
4. Enquanto isso, o `useModels.refresh()` pode executar e buscar lista de modelos do servidor
|
|
5. O servidor ainda retorna modelo A (antigo) pois a troca não completou
|
|
6. `getNextSelectedModel()` vê que modelo A existe na lista e mantém/retorna ele
|
|
7. Resultado: o usuário vê modelo A selecionado em vez de B
|
|
|
|
**Solução:**
|
|
Implementar um mecanismo de "lock" temporário no `useModels` que previne que o refresh automático sobrescreva o `selectedModel` por alguns segundos após uma seleção manual do usuário.
|
|
|
|
## Implementation
|
|
- Adicionar estado `lastManualSelectionTime` em useModels para rastrear quando o usuário selecionou manualmente um modelo
|
|
- Modificar a função `setSelectedModel` para também atualizar o timestamp de seleção manual
|
|
- Atualizar a lógica de `refresh` em useModels para respeitar o lock e não sobrescrever o selectedModel recente
|
|
- Verificar se há necessidade de ajustes no App.tsx ou Sidebar.tsx para integrar com a nova API
|
|
- Testar a correção simulando a troca de modelo e verificando que o modelo correto permanece selecionado
|
|
|
|
## Required Specs
|
|
<!-- SPECS_START -->
|
|
<!-- SPECS_END --> |