Files
nas-runbooks/hermes-tt/nyora-notes-tt-phase2-embedding-relance-post-sweep-08-08-2026.md

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 :

  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