Blomios
8e481aed69
Versionne l'état runtime IdeA produit pendant le sprint #13 : store de tickets (dont les nouveaux #55 à #67), compteur et index, notes de mémoire projet des lots F0 à F5, et journal des tâches de fond. Séparé du code applicatif conformément à la convention du dépôt (cf.ad1f225,a244f32) : métadonnée d'orchestration last-writer-wins, sans impact sur le build. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
28 lines
2.7 KiB
Markdown
28 lines
2.7 KiB
Markdown
---
|
|
issueRef: "#55"
|
|
version: 11
|
|
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
|
|
updatedAt: 1784097757001
|
|
---
|
|
## Réouverture (2026-07-15) — le fix 141c13d ne suffit pas
|
|
|
|
Le fix #55 (commit 141c13d) a supprimé le timeout **prématuré** (~5 s) en distinguant process vivant-en-warmup / mort, avec `ReadinessPolicy::warmup_deadline = 120 s`. Mais l'utilisateur reproduit toujours « model server error (timeout): readiness timed out » **au lancement d'IdeA**, et ça finit par marcher après plusieurs essais.
|
|
|
|
### Cause racine
|
|
`crates/application/src/model_server.rs` → `wait_for_started_server` (~l.437) : tant que process `Running` + endpoint `Unreachable`, poll jusqu'à `deadline = now + warmup_deadline` (120 s), puis `stop_started_server` + `ModelServerError::Timeout`.
|
|
|
|
- **1er lancement à froid** : page cache OS froid, GGUF multi-Go, chargement RAM/VRAM, I/O disque en concurrence avec le reste du boot IdeA ⇒ warmup > 120 s ⇒ timeout + kill.
|
|
- **Essais suivants** : fichier en page cache chaud ⇒ chargement < 120 s ⇒ succès. Explique le « au bout de plusieurs essais ça finit ».
|
|
|
|
### Fix Lot 1 backend (livré, commit f7cae4c sur feature/ticket55-model-warmup-deadline)
|
|
Cadré par Architect (mémoire `architecture-local-model-readiness-timeout`), approche A configurable :
|
|
- Défaut `ReadinessPolicy::warmup_deadline` : 120 s → **600 s** (`crates/application/src/model_server.rs`).
|
|
- Nouveau `LocalModelServerConfig::warmup_deadline_secs: Option<u64>`, rétrocompatible, validation stricte `[30, 1800]` (`crates/domain/src/model_server.rs`).
|
|
- Policy effective dérivée **par config serveur** (deadline par-serveur), `probe`/`backoff` gardés séparés. DTO IPC `warmupDeadlineSecs` (`app-tauri/dto.rs`).
|
|
- Contrat readiness inchangé : Exited⇒échec rapide ; Running+HTTP OK⇒prêt ; Running+HTTP KO⇒continuer jusqu'à deadline ; Running au-delà⇒stop+Timeout.
|
|
|
|
### QA — VERT (ports mockés)
|
|
`cargo test -p domain` (252), `-p application` (81 + 22 model_server ciblés), `-p app-tauri --test dto_model_servers` (6), `-p infrastructure model_server` (2), build OK. Tests clés : slow_local_warmup...succeeds_without_stop, warmup_deadline_reached_returns_timeout_and_stops, process_exit_during_warmup_fails_fast, effective_policy_uses_configured_deadline, default_is_ten_minutes, hors-bornes⇒INVALID.
|
|
|
|
### RESTE À FAIRE — vérification manuelle utilisateur (bloquant merge)
|
|
Les tests prouvent le **mécanisme**, PAS que 600 s guérit le vrai cold-start `llama-server` (bind réel hors sandbox). Git a committé mais **retient le merge sur develop** jusqu'à confirmation « cold-start OK » de l'utilisateur (vrai lancement à froid, après reboot / cache purgé). develop non divergé (ce5aa28) ⇒ merge --no-ff trivial au feu vert. |