chore(tickets): synchronise l'état runtime des tickets et du contexte main

Met à jour l'index/compteur de tickets, les tickets #111/#113/#114 et le
contexte de Main suite au traitement du ticket #114.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
2026-07-30 12:56:07 +02:00
parent 9b1ced50be
commit 5be5c5975e
10 changed files with 164 additions and 11 deletions

View File

@ -1,6 +1,69 @@
---
issueRef: "#111"
version: 2
updatedBy: {"kind":"user"}
updatedAt: 1785331658707
version: 3
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
updatedAt: 1785390694060
---
## Enquete `/tmp` IdeA — inventaire et fenetres de cleanup
### Methode
- Scan du code sur les usages `std::env::temp_dir()` / prexifes `idea-*` hors `frontend`.
- Lecture des blocs source pour separer `runtime` vs `#[cfg(test)]`.
- Verification du contenu live de `/tmp` au moment de l'analyse : aucun dossier `idea-*` visible a la racine de `/tmp` pendant ce tour.
### Conclusion courte
- Les noms cites dans le ticket (`idea-structured-session-factory-*`, `idea-web-root-*`, `idea-server-test-*`, `idea-openai-compat-*`, etc.) ne correspondent pas, dans l'etat actuel du code, a des artefacts runtime produit. Ils proviennent majoritairement de tests embarques dans les crates Rust.
- Le seul artefact runtime clair lie a IdeA/MCP trouve pendant l'analyse est le repertoire parent `idea-mcp` qui heberge les sockets Unix par projet quand le runtime tombe sur `/tmp` comme base.
- Donc le modele `un call MCP -> un dossier temp -> suppression en fin de call` n'est pas le bon modele pour la majorite des cas observes.
### Runtime reel identifie
#### 1. `idea-mcp` (runtime MCP par projet)
- Source : `crates/backend/src/mcp_endpoint.rs` et miroir `crates/app-tauri/src/mcp_endpoint.rs`.
- Role : repertoire parent des sockets Unix du serveur MCP local, ex. `<runtime-dir>/idea-mcp/<project-id>.sock`.
- Creation : a la determination du endpoint MCP du projet si le sous-dossier `idea-mcp` n'existe pas deja.
- Granularite : par projet / par listener MCP, pas par appel d'outil MCP.
- Cleanup deja present :
- le fichier socket est unlink sur fermeture propre via `reclaim_name(true)` ;
- un socket cadavre est supprime avant rebind si c'est bien un socket stale ;
- refs utiles : `crates/backend/src/lib.rs` autour de `bind_endpoint()` et `crates/backend/src/mcp_endpoint.rs`.
- Cleanup opportun :
- **pas** a la fin de chaque call MCP ;
- **oui** a la fermeture du listener / fermeture du projet pour le fichier `.sock` ;
- **oui** au prochain demarrage / prochain bind pour nettoyer un socket stale d'un crash precedent ;
- **amelioration possible** : supprimer aussi le dossier parent `idea-mcp` s'il devient vide apres drop du dernier socket, ou faire un sweep best-effort au demarrage des endpoints MCP.
- Importance : c'est le seul candidat clairement runtime et potentiellement visible sous `/tmp` si `XDG_RUNTIME_DIR` / `TMPDIR` ne sont pas utilisables et que le fallback tombe sur `/tmp`.
### Faux positifs / test-only observes
Ces prefixes existent dans le code mais dans des blocs de tests ou helpers de test. Ils ne semblent pas correspondre a des dossiers runtime utilisateur :
- `idea-openai-compat-*` : `crates/infrastructure/src/session/openai_compat.rs`
- `idea-structured-session-*` : `crates/infrastructure/src/session/mod.rs`
- `idea-web-root-*`, `idea-server-test-*`, `idea-server-lock-*`, `idea-app-data-env-*`, `idea-shared-core-*`, `idea-empty-web-*` : `crates/web-server/src/lib.rs`
- `idea-embedded-server-*` : `crates/app-tauri/src/embedded_server.rs`
- `idea-openai-mcp-tools-list-*`, `idea-openai-mcp-permissions-*`, variantes `app-tauri-*` : tests dans `crates/backend/src/openai_tools.rs` et `crates/app-tauri/src/openai_tools.rs`
- `idea-pty-sandbox-*`, `idea-landlock-*`, `idea-opencode-*`, `idea-devices-store-*`, `idea-secrets-store-*`, etc. : helpers de tests avec `Drop`/`remove_dir_all`.
### Lecture sur leur cleanup
- Dans la majorite des cas de tests lus, le cleanup nominal existe deja (`Drop`, `remove_dir_all`, `remove_file`).
- Le vrai risque residuel de ces dossiers est surtout : crash/abort de test, kill brutal, ou interruption d'une suite de tests. Dans ce cas, le residue reste dans `/tmp`.
- Comme `/tmp` est borne a 16 Go, ces residues peuvent devenir un probleme d'hygiene, mais ce n'est pas un sujet de lifecycle MCP par call ; c'est plutot un sujet de hygiene de tests / sweep de reliquats.
### Fenetres de cleanup recommandes
#### Runtime produit
- `idea-mcp/<project>.sock` : cleanup a la fermeture du listener MCP (deja en place) ; stale cleanup avant bind (deja en place).
- `idea-mcp/` parent dir : cleanup best-effort si vide apres fermeture du dernier listener, ou sweep au demarrage de l'app / ouverture projet.
#### Artefacts de tests
- Cleanup nominal dans chaque test/helper (souvent deja fait).
- Ajouter si besoin un sweep best-effort des prefixes `idea-*` generes par les tests au debut/fin des jobs de test locaux/CI.
- Ne pas melanger cela avec la logique runtime MCP : c'est un chantier distinct.
### Recommandation de perimetre pour le ticket #111
1. Cadrer `#111` sur les **artefacts runtime** visibles par l'utilisateur.
2. Traiter en priorite `idea-mcp` :
- verifier si le dossier parent vide reste parfois en place ;
- si oui, le supprimer quand il devient vide ou au prochain demarrage.
3. Ouvrir si necessaire un second ticket dedie a l'hygiene des reliquats de tests sous `/tmp`.
### Reponse a la question produit initiale
- Oui, IdeA peut produire un artefact sous `/tmp` pour le MCP runtime (`idea-mcp`), mais ce n'est pas cree par appel MCP individuel.
- Non, les dossiers cites dans la description ne semblent pas, a ce stade, etre crees par les appels MCP IdeA de production ; ils sont majoritairement issus de tests.

View File

@ -9,9 +9,9 @@ links: []
agentRefs: []
attachments: []
createdBy: {"kind":"user"}
updatedBy: {"kind":"user"}
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
createdAt: 1785331481527
updatedAt: 1785331658707
version: 2
updatedAt: 1785390694060
version: 3
---
dans le dossier /tmp, je vois enormement de dossier du genre : idea-structured-session-factory-openai-e5bbdcac-0405-4ce3-be82-00d9639ee648 ou encore idea-web-root-4fbc4144-065c-4915-9e05-9f6fec20aa3b ou idea-server-test-863efbe5-5098-4f34-aab8-1ba5047f4209 ou idea-openai-compat-unreachable-f713f5fa-5469-4875-96f9-242f7913441b ou idea-openai-compat-tools-rejected-d000d319-8c11-4585-8a16-6ae8a3b45c49 ou idea-openai-compat-status-422-9fd4b27f-e0c1-4043-9fb9-72dcf8d2c2e1 ou idea-openai-compat-single-final-940b1d63-6d4a-40b0-953a-0f3279ec2bdc etc qui sont visiblement créé par IdeA. J'aiemrais que pour un maximum d'entre eux, on puisse clean ça au bon momment. Il faut donc identifier ce qui créé ce cache, puis le supprimer quand ce cache n'est plus utile.