5.0 KiB
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 :
- Phase 2 (
extract_attachments_phase2.py, limit=200 par passage) en boucle jusqu'aremaining_pending<=0(max 10 passages, garde-fou). - Embedding (
embed_attachments.py, pas de limite -- traite tout ce qui estextraction_status='processed'et pas encore dansattachments_vec). - Audit : requete recap
content_hash/ao_reference/attachments_vec/ JOIN exact aveconedrive_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.shreutilisable tel quel pour toute relance future (idempotent : ne retraite que ce qui estpending/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_vecmis a jour sur les PJ traitees lors de ce passage