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>
1.6 KiB
id, number, title, status, priority, sprint, links, agentRefs, createdBy, updatedBy, createdAt, updatedAt, version
| id | number | title | status | priority | sprint | links | agentRefs | createdBy | updatedBy | createdAt | updatedAt | version | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 83d320f1-766b-4744-b518-8e39a2518e9c | 31 | Détection de profils séquentielle : N × 800 ms au pire, résultat potentiellement partiel | closed | low | e28a4d53-8bd2-446a-b0ac-2a017373b8b2 |
|
|
|
1783491197541 | 1784064442657 | 4 |
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 ×.