Files
IdeA/.ideai/tickets/31/issue.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

1.6 KiB
Raw Blame History

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
target kind
#28 relatesTo
kind agent_id
agent a6ced819-b893-4213-b003-9e9dc79b9641
kind agent_id
agent a6ced819-b893-4213-b003-9e9dc79b9641
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 ×.