runbook: nyora-notes-tt phase2+embedding relance post-sweep 08-08-2026

2026-08-08 04:18:27 +00:00
parent 69f8a8b31c
commit a25bb4ee88
1 changed files with 97 additions and 0 deletions
@@ -0,0 +1,97 @@
 # nyora-notes-tt : fin du sweep Phase 1, relance Phase 2 + embedding sur le volume complet (08/08/2026)
 **Date** : 08/08/2026
 **Instance** : hermes-tt
 **Contexte** : suite directe de `nyora-notes-tt-sweep-livelock-fix-08-08-2026.md` et
 `nyora-notes-tt-ao-reference-endpoint-pj-archive-fix-08-08-2026.md` (meme chantier, session
 suivante). Action demandee par Nabil en fin de session precedente : surveiller la fin du
 sweep Phase 1 puis enchainer Phase 2 (extraction) + embedding sur le volume complet de PJ,
 sans attendre une nouvelle session.
 ## 1. Fin du sweep Phase 1 (confirmee, pas d'intervention necessaire)
 Le sweep `run_batch_sweep_all_years.sh` (lance le 07/08 21h58, deja passe par le fix
 livelock `scan_fail_count`) a atteint son plafond `MAX_BATCHES=15` de lui-meme, sans aucune
 intervention :
 ```
 [2026-08-08 02:22:41] Lot 15 termine, code retour=0
 [2026,08-08 02:22:42] === FIN sweep toutes annees : 3 notes restantes ===
 ```
 Les 3 notes restantes sont exactement les 3 notes a timeout OWA permanent deja identifiees
 dans le runbook du livelock (`note_8daed11d2468`, `note_3bbba52d709b`, `note_8c56696597e7`) --
 comportement attendu, decision deja actee de ne pas investiguer la cause OWA tant que ca
 reste marginal. Aucune boucle infinie : le plafond de lots protege bien contre ce risque,
 comme concu.
 ## 6. Nouveau script : run_phase2_embed_full.sh
 Cree pour cette relance, sur le meme modele que `run_batch_sweep_all_years.sh` (boucle avec
 condition d'arret + log horodate). Chaine trois etapes :
 1. **Phase 2** (`extract_attachments_phase2.py`, limit=200 par passage) en boucle jusqu'a
   `remaining_pending<=0` (max 10 passages, garde-fou).
 2. **Embedding** (`embed_attachments.py`, pas de limite -- traite tout ce qui est
   `extraction_status='processed'` et pas encore dans `attachments_vec`).
 3. **Audit** : requete recap `content_hash` / `ao_reference` / `attachments_vec` / JOIN exact
   avec `onedrive_documents`.
 **Piege rencontre et corrige** : l'etape d'audit utilise un heredoc Python (`docker exec -i
 ... python3 - << 'PYEOF'`). Le `-i` sur `docker exec` est indispensable pour que le heredoc
 soit transmis en stdin au conteneur -- sans lui, `python3 -` ne recoit rien. A reutiliser
 pour tout futur script qui pipe du Python inline dans un `docker exec`.
 **Deuxieme piege (mineur, corrige en session)** : la premiere version de la requete d'audit
 inline n'appelait pas `sqlite_vec.load(conn)` avant de lire `attachments_vec` ->
 `OperationalError: no such module: vec0`. Meme piege que documente ailleurs pour
 `embed_attachments.py` (chargement vec0 obligatoire avant toute requete sur les tables
 `*_vec`). Corrige en relancant seulement l'audit avec le chargement d'extension.
 Deploiement : script pousse sur le NAS par transfert base64 (evite tout probleme
 d'echappement de guillemets a travers les couches mcp-nas -> ssh -> heredoc), puis lance en
 arriere-plan (`nohup ... & disown`) sur le host via SSH `Best0f@172.17.0.1:22222` (alias
 `nas-host`, deja configure cote mcp-nas) -- **`Best0f` est dans le groupe `docker`, aucun
 besoin de `sudo`** pour les `docker exec`/`docker ps` (contrairement a `claude-ops`, absent
 de ce conteneur mcp-nas).
 ## 3. Resultat
 Phase 2 : 1 succes / 3 erreurs sur le dernier passage (le reste du volume avait deja ete
 absorbe par les passages precedents en cours de session), `remaining_pending=0` -- plus rien
 en attente d'extraction sur les PJ telechargees.
 Embedding : 14 -> 24 (10 nouveaux embeddings, 0 erreur).
 ## 4. Audit final (08/08/2026, apres chaine complete)
 | Metrique | Valeur |
 |---|---|
 | PJ totales identifiees | 49 |
 | Telechargees avec succes | 27 |
 | Echec telechargement (OWA, hors scope) | 22 |
 | `content_hash` calcule | 27 (100% des telechargees) |
 | `ao_reference` extraite | 23 (85% des telechargees) |
 | Extraction reussie | 24 |
 | Extraction en echec permanent | 3 |
 | `attachments_vec` (embeddings) | 24 (100% des extraites) |
 | JOIN exact `content_hash` avec `onedrive_documents` | 3 (1 seul au 08/08 matin -- en hausse, confirme l'hypothese de rattrapage progressif) |
 | Notes non scannees restantes | 3 |
 Couverture consideree bonne : tout ce qui est techniquement telechargeable et extractible
 l'est. Les echecs restants (22 telechargement + 3 extraction) sont des cas OWA/format deja
 identifies, acceptes comme limite connue, pas d'action prevue sauf si le phenomene s'etend.
 ## Decisions actees, ne pas rouvrir
 - Ne pas relancer le sweep Phase 1 pour les 3 notes bloquees (cf runbook livelock).
 - Ne pas investiguer les 22 echecs de telechargement OWA sauf extension du phenomene.
 - `run_phase2_embed_full.sh` reutilisable tel quel pour toute relance future (idempotent :
  ne retraite que ce qui est `pending`/`error`, ne recree pas les embeddings existants).
 ## Fichiers modifies / crees
 - `/volume1/docker/nyora-notes-tt/run_phase2_embed_full.sh` (nouveau)
 - `/volume1/docker/nyora-notes-tt/phase2_embed_full_20260808_050903.log` (log d'execution)
 - DB `nyora-notes-tt.db` : `content_hash`, `ao_reference`, `extraction_status`,
  `attachments_vec` mis a jour sur les PJ traitees lors de ce passage