Blomios
2fa226e413
`.ideai/tickets/` et `.ideai/sprints/` sont le registre durable du projet (les tickets sont déjà référencés par les messages de commit : #14, #21..#25, #28), au même titre que `.ideai/memory/`. Ils entrent donc dans le dépôt. À l'inverse, `.ideai/background-tasks/` (snapshots de rendez-vous headless) et `.ideai/proposals/` (amendements de contexte en attente d'arbitrage) restent de l'état d'exécution transitoire, de la même classe que `live-state.json` et `.ideai/requests/` : ils doivent être ignorés (patch `.gitignore` à venir). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
31 lines
1.6 KiB
Markdown
31 lines
1.6 KiB
Markdown
---
|
||
id: "83d320f1-766b-4744-b518-8e39a2518e9c"
|
||
number: 31
|
||
title: "Détection de profils séquentielle : N × 800 ms au pire, résultat potentiellement partiel"
|
||
status: "open"
|
||
priority: "low"
|
||
sprint: null
|
||
links: [{"target":"#28","kind":"relatesTo"}]
|
||
agentRefs: []
|
||
createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
|
||
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
|
||
createdAt: 1783491197541
|
||
updatedAt: 1783491197541
|
||
version: 1
|
||
---
|
||
## Origine
|
||
Relevé par Git en revue du diff du ticket #28 (merge 710fa8f), hors périmètre du fix.
|
||
|
||
## Constat
|
||
Depuis #28, `DetectProfiles::execute` séquence les `await` candidat par candidat, chaque sonde bornée par `tokio::time::timeout(800ms)`. N profils indisponibles coûtent donc **N × 800 ms** au pire.
|
||
|
||
Côté frontend, `DETECT_TIMEOUT_MS = 3 s` relâche le flag `detecting`. À partir de ~4 candidats muets, le tour de détection dépasse ce délai : l'indicateur « Detecting… » disparaît avant que les résultats n'arrivent.
|
||
|
||
## Impact
|
||
Cosmétique. L'UI **ne gèle plus** (c'est bien l'objet de #28, corrigé) ; le risque résiduel est un affichage de disponibilité qui arrive après la retombée de l'indicateur.
|
||
|
||
## Piste de fix
|
||
Paralléliser les sondes avec `futures::future::join_all` dans `DetectProfiles::execute` (`crates/application/src/agent/usecases.rs`) : le coût au pire retombe à ~800 ms quel que soit N, largement sous le timeout UI.
|
||
|
||
## Validation
|
||
Test `#[tokio::test(flavor = "multi_thread")]` sur `DetectProfiles::execute` avec N candidats muets, asserting que la durée totale reste bornée par ~1 × timeout et non N ×. |