From a25bb4ee8840dae6a266388b1edd5f6304a2e59c Mon Sep 17 00:00:00 2001 From: bolbol Date: Sat, 8 Aug 2026 04:18:27 +0000 Subject: [PATCH] runbook: nyora-notes-tt phase2+embedding relance post-sweep 08-08-2026 --- ...embedding-relance-post-sweep-08-08-2026.md | 97 +++++++++++++++++++ 1 file changed, 97 insertions(+) create mode 100644 hermes-tt/nyora-notes-tt-phase2-embedding-relance-post-sweep-08-08-2026.md diff --git a/hermes-tt/nyora-notes-tt-phase2-embedding-relance-post-sweep-08-08-2026.md b/hermes-tt/nyora-notes-tt-phase2-embedding-relance-post-sweep-08-08-2026.md new file mode 100644 index 0000000..5fe13db --- /dev/null +++ b/hermes-tt/nyora-notes-tt-phase2-embedding-relance-post-sweep-08-08-2026.md @@ -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