blomios/IdeA
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
8fe93d165208e664ef7ab557d87c979308fccf6b
IdeA/.ideai/tickets/55/carnet.md
Blomios 8e481aed69 chore(ideai): état d'orchestration du sprint #13 (transport HTTP/WS + surface web) 
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>
2026-07-16 10:32:39 +02:00

2.7 KiB
Raw Blame History

issueRef, version, updatedBy, updatedAt
issueRef version updatedBy updatedAt
#55 11
kind agent_id
agent a6ced819-b893-4213-b003-9e9dc79b9641
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.