Relevé : un délai et un journal par étape, et /etat porte « motif » (à afficher par le front Svelte) #1625

Merged

hermes-fusion merged 4 commits from hermes/releve-delai-etape into main 2026-10-15 15:50:03 +02:00

Conversation 4 Commits 4 Files changed 12 +1292 -90

hermes-bot commented 2026-10-14 19:32:01 +02:00

Collaborator

• Copy link
• Copy Markdown

Carte : t_990ea299 (Atelier Hermes). Le relevé du tableau 132 échouait en « code -1 ».

La panne, mesurée le 2026-10-14. Le bouton « Actualiser » affichait « Le relevé a échoué (code -1) : chiffres précédents conservés ». Lancé à la main sur le 132, le même relevé finit en code 0 mais en 366 s, dont 358 s sans une seule ligne ; le parent (serveur.lancer_collecte), lui, le tue à 300 s et jetait la sortie d'erreur de l'enfant (elle n'était écrite qu'au retour normal). Vérifié sur l'ancien code, avec un enfant qui écrit deux lignes puis ne finit pas :

collecte manuelle en echec : Command '...' timed out after 2 seconds
code = -1

Ses deux lignes sont perdues, donc aucune étape nommable : c'est ce qui donnait « code -1 » sans cause.

Cause. Le relevé n'avait aucun plafond de temps à lui. Une étape lente — service qui n'en finit pas, machine absente, reprises 401 qui s'additionnent — consommait à elle seule le délai du bouton, et tout le relevé était tué avec elle.

Remède. Le délai de 300 s ne bouge pas : c'est le relevé qui doit tenir dedans.

Morceau	Quoi
_tableau/etapes.py (nouveau)	journal horodaté des étapes (début, note, fin, durée) sur la sortie d'erreur et dans journal-collecte.log ; délai par étape (SIGALRM, fil principal) ; budget du relevé entier à 270 s, dont 20 gardés pour l'écriture de la page ; etape_en_cours(), qui relit le journal
_tableau/tableau-bord.py	une étape déclarée par morceau : « chaîne X » (reprise 401 comprise), « TikTok @… », « Instagram @… », « sujets … », « rendu de la page ». Une étape abandonnée garde les chiffres précédents, sa carte porte le motif, et le relevé continue avec les autres
_tableau/collecte.py	notes de journal aux attentes de la phase muette (reprises 401, porte Analytics, chiffres, liste des mises en ligne, rapport reach) ; motif_echec y déménage (plafond de lignes de tableau-bord.py)
_tableau/serveur.py	la sortie de l'enfant est écrite au journal du service même quand il est tué ; l'étape en cours est lue dans son journal
_tableau/tableau.js	le bouton affiche le motif au lieu de « code -1 »
_tableau/test_releve_delai.py (nouveau)	étape factice lente, bouton d'une carte, budget épuisé, enfant tué par le parent

Champ de l'API à faire suivre côté front (prévenir svelte). GET /etat porte un champ ajouté : motif (texte, null quand tout va bien). _tableau/tableau.js l'affiche déjà ; le cadre Svelte (front/src/Cadre.svelte, ligne 153) affiche encore « Le relevé a échoué (code ${s.code}). » — une ligne à changer, s.motif || \code ${s.code}``. Je ne touche pas au front.

Preuves.

$ python3 _tableau/test_releve_delai.py
OK : une étape lente est abandonnée seule, le relevé continue et la vraie cause est dite
code=0

Sur origin/main (arbre de travail séparé, git worktree add --detach … origin/main) ce banc ne peut pas passer : etapes.py n'existe pas et /etat ne porte pas motif. Il reproduit donc la panne avant le correctif.

$ python3 _tableau/lancer-tests.py --tout
… 3 rouges, les MÊMES sur origin/main mesuré dans cet environnement :
   test_deploy_132.py (la simulation du script), test_retours_attente.py
   (PermissionError sur /tmp/reception-desc.md, fichier d'un autre utilisateur),
   test_retours_validation.py (FileNotFoundError : 'multica').
   Cliquet de couverture : cœur 97,9 % ici et 97,9 % sur origin/main — la baisse
   est celle de l'environnement, pas de cette branche.

$ cd _tableau/rust && cargo test --release --locked    → CODE=0 (38 tests, 0 échec)
$ cd _tableau/rust && cargo build --release --locked   → CODE=0

Couverture de ce qui est ajouté : etapes.py 100 %, test_releve_delai.py 100 %.

À déployer. _tableau/etapes.py (nouveau), tableau-bord.py, collecte.py, serveur.py, tableau.js : _tableau/deploy-132.sh les recopie (son filtre prend _tableau/*.py, *.js) et redémarre studio-web. Aucune donnée, aucune unité systemd, rien à construire.

Ce qui reste ouvert. Le relevé complet demande 366 s mesurées pour huit chaînes : le budget de 270 s abandonnera donc des chaînes tant que cette durée n'aura pas baissé (elles gardent leurs chiffres et le disent, sur leur carte). Le journal des étapes — /opt/studio/journal-collecte.log, réécrit à chaque passage — donne désormais, par chaîne, sa durée et son temps d'attente : c'est la mesure qui manquait pour décider (piste : lire les huit chaînes ensemble plutôt que l'une après l'autre).

Ce que je n'ai pas mesuré. La répartition des 358 s sur le 132 (pas d'accès à la machine ni aux jetons) ; la durée d'un relevé après le correctif.

Carte : t_990ea299 (Atelier Hermes). Le relevé du tableau 132 échouait en « code -1 ». **La panne, mesurée le 2026-10-14.** Le bouton « Actualiser » affichait « Le relevé a échoué (code -1) : chiffres précédents conservés ». Lancé à la main sur le 132, le même relevé finit en **code 0 mais en 366 s, dont 358 s sans une seule ligne** ; le parent (`serveur.lancer_collecte`), lui, le tue à 300 s et **jetait la sortie d'erreur de l'enfant** (elle n'était écrite qu'au retour normal). Vérifié sur l'ancien code, avec un enfant qui écrit deux lignes puis ne finit pas : ``` collecte manuelle en echec : Command '...' timed out after 2 seconds code = -1 ``` Ses deux lignes sont perdues, donc aucune étape nommable : c'est ce qui donnait « code -1 » sans cause. **Cause.** Le relevé n'avait aucun plafond de temps à lui. Une étape lente — service qui n'en finit pas, machine absente, reprises 401 qui s'additionnent — consommait à elle seule le délai du bouton, et tout le relevé était tué avec elle. **Remède.** Le délai de 300 s ne bouge pas : c'est le relevé qui doit tenir dedans. | Morceau | Quoi | |---|---| | `_tableau/etapes.py` (nouveau) | journal horodaté des étapes (début, note, fin, durée) sur la sortie d'erreur **et** dans `journal-collecte.log` ; délai par étape (`SIGALRM`, fil principal) ; budget du relevé entier à 270 s, dont 20 gardés pour l'écriture de la page ; `etape_en_cours()`, qui relit le journal | | `_tableau/tableau-bord.py` | une étape déclarée par morceau : « chaîne X » (reprise 401 comprise), « TikTok @… », « Instagram @… », « sujets … », « rendu de la page ». Une étape abandonnée garde les chiffres précédents, sa carte porte le motif, et le relevé continue avec les autres | | `_tableau/collecte.py` | notes de journal aux attentes de la phase muette (reprises 401, porte Analytics, chiffres, liste des mises en ligne, rapport reach) ; `motif_echec` y déménage (plafond de lignes de `tableau-bord.py`) | | `_tableau/serveur.py` | la sortie de l'enfant est écrite au journal du service **même quand il est tué** ; l'étape en cours est lue dans son journal | | `_tableau/tableau.js` | le bouton affiche le motif au lieu de « code -1 » | | `_tableau/test_releve_delai.py` (nouveau) | étape factice lente, bouton d'une carte, budget épuisé, enfant tué par le parent | **Champ de l'API à faire suivre côté front (prévenir `svelte`).** `GET /etat` porte un champ **ajouté** : `motif` (texte, `null` quand tout va bien). `_tableau/tableau.js` l'affiche déjà ; le cadre Svelte (`front/src/Cadre.svelte`, ligne 153) affiche encore « Le relevé a échoué (code ${s.code}). » — une ligne à changer, `s.motif || \`code ${s.code}\``. Je ne touche pas au front. **Preuves.** ``` $ python3 _tableau/test_releve_delai.py OK : une étape lente est abandonnée seule, le relevé continue et la vraie cause est dite code=0 ``` Sur `origin/main` (arbre de travail séparé, `git worktree add --detach … origin/main`) ce banc ne peut pas passer : `etapes.py` n'existe pas et `/etat` ne porte pas `motif`. Il reproduit donc la panne avant le correctif. ``` $ python3 _tableau/lancer-tests.py --tout … 3 rouges, les MÊMES sur origin/main mesuré dans cet environnement : test_deploy_132.py (la simulation du script), test_retours_attente.py (PermissionError sur /tmp/reception-desc.md, fichier d'un autre utilisateur), test_retours_validation.py (FileNotFoundError : 'multica'). Cliquet de couverture : cœur 97,9 % ici et 97,9 % sur origin/main — la baisse est celle de l'environnement, pas de cette branche. $ cd _tableau/rust && cargo test --release --locked → CODE=0 (38 tests, 0 échec) $ cd _tableau/rust && cargo build --release --locked → CODE=0 ``` Couverture de ce qui est ajouté : `etapes.py` 100 %, `test_releve_delai.py` 100 %. **À déployer.** `_tableau/etapes.py` (nouveau), `tableau-bord.py`, `collecte.py`, `serveur.py`, `tableau.js` : `_tableau/deploy-132.sh` les recopie (son filtre prend `_tableau/*.py`, `*.js`) et redémarre `studio-web`. Aucune donnée, aucune unité systemd, rien à construire. **Ce qui reste ouvert.** Le relevé complet demande 366 s mesurées pour huit chaînes : le budget de 270 s abandonnera donc des chaînes tant que cette durée n'aura pas baissé (elles gardent leurs chiffres et le disent, sur leur carte). Le journal des étapes — `/opt/studio/journal-collecte.log`, réécrit à chaque passage — donne désormais, par chaîne, sa durée et son temps d'attente : c'est la mesure qui manquait pour décider (piste : lire les huit chaînes ensemble plutôt que l'une après l'autre). **Ce que je n'ai pas mesuré.** La répartition des 358 s sur le 132 (pas d'accès à la machine ni aux jetons) ; la durée d'un relevé après le correctif.

hermes-bot added 1 commit 2026-10-14 19:32:02 +02:00

Relevé : chaque étape a son délai et son journal, et la page dit la vraie cause ... 72750e9a4f

Panne mesurée le 2026-10-14 sur le LXC 132 : le bouton « Actualiser » affichait « Le relevé a échoué
(code -1) : chiffres précédents conservés ». `serveur.lancer_collecte` tuait le relevé à 300 s, et la
sortie d'erreur de l'enfant était perdue — elle n'était écrite qu'au retour normal. Lancé à la main, le
même relevé finit en code 0 mais en 366 s, dont 358 s sans une seule ligne.

Cause : le relevé n'avait aucun plafond de temps à lui. Une étape lente (service qui n'en finit pas,
machine absente, reprises 401 qui s'additionnent) consommait à elle seule le délai du bouton ; tout le
relevé était tué avec elle, et rien ne pouvait dire à quelle étape.

Remède :
- etapes.py : journal horodaté des étapes (début, note, fin, durée), délai par étape (SIGALRM, fil
  principal), budget du relevé entier à 270 s — sous les 300 s du bouton, qui ne bouge pas ;
- tableau-bord.py : chaque étape déclarée (chaîne, TikTok, Instagram, sujets, rendu) ; une chaîne
  abandonnée garde ses chiffres précédents, sa carte porte le motif, le relevé continue ;
- collecte.py : notes aux attentes de la phase muette ; motif_echec y déménage (plafond de lignes) ;
- serveur.py : la sortie de l'enfant est écrite même quand il est tué ; /etat porte motif ;
- tableau.js : le bouton affiche motif au lieu de « code -1 » ;
- test_releve_delai.py : étape factice lente, bouton de carte, budget épuisé, enfant tué par le parent.

hermes-bot force-pushed hermes/releve-delai-etape from 72750e9a4f to ce9cd7b5d7 2026-10-14 19:33:16 +02:00 Compare

hermes-bot force-pushed hermes/releve-delai-etape from ce9cd7b5d7 to d483e330b8 2026-10-14 20:07:02 +02:00 Compare

hermes-bot force-pushed hermes/releve-delai-etape from d483e330b8 to dbb9ed94fe 2026-10-14 20:38:38 +02:00 Compare

hermes-fusion added the

conflit

label 2026-10-14 21:10:02 +02:00

hermes-fusion commented 2026-10-14 21:10:03 +02:00

Collaborator

• Copy link
• Copy Markdown

fusion-auto : pas de fusion, la PR est en conflit avec main : à rebaser. Le chef de l'atelier renvoie la carte à l'agent ; l'étiquette tombera d'elle-même une fois corrigé.

`fusion-auto` : pas de fusion, la PR est en conflit avec main : à rebaser. Le chef de l'atelier renvoie la carte à l'agent ; l'étiquette tombera d'elle-même une fois corrigé.

hermes-bot force-pushed hermes/releve-delai-etape from dbb9ed94fe to 46a1cc45fc 2026-10-14 21:20:22 +02:00 Compare

hermes-fusion removed the

conflit

label 2026-10-14 21:25:02 +02:00

hermes-fusion added the

conflit

label 2026-10-14 23:30:08 +02:00

hermes-fusion commented 2026-10-14 23:30:08 +02:00

Collaborator

• Copy link
• Copy Markdown

fusion-auto : pas de fusion, la PR est en conflit avec main : à rebaser. Le chef de l'atelier renvoie la carte à l'agent ; l'étiquette tombera d'elle-même une fois corrigé.

`fusion-auto` : pas de fusion, la PR est en conflit avec main : à rebaser. Le chef de l'atelier renvoie la carte à l'agent ; l'étiquette tombera d'elle-même une fois corrigé.

hermes-bot referenced this pull request 2026-10-14 23:53:27 +02:00

Accueil — la monetisation par chaine et la duree moyenne des longs ecrites a chaque collecte (STUD-1224, revue du 14/10) #1680

hermes-bot referenced this pull request 2026-10-15 13:17:19 +02:00

Tableau : nouvelle route GET /api/releves, la fraîcheur de chaque relevé (t_6c90882a) #1728

hermes-bot force-pushed hermes/releve-delai-etape from 46a1cc45fc to 1201136c58 2026-10-15 15:27:20 +02:00 Compare

hermes-bot force-pushed hermes/releve-delai-etape from 1201136c58 to 214e764d3b 2026-10-15 15:40:36 +02:00 Compare

hermes-fusion removed the

conflit

label 2026-10-15 15:45:02 +02:00

hermes-fusion merged commit 48c4af118d into main 2026-10-15 15:50:03 +02:00

hermes-fusion deleted branch hermes/releve-delai-etape 2026-10-15 15:50:03 +02:00

hermes-fusion commented 2026-10-15 15:50:03 +02:00

Collaborator

• Copy link
• Copy Markdown

Fusionnée automatiquement par fusion-auto (forge) : CI verte, sans conflit.

Fusionnée automatiquement par `fusion-auto` (forge) : CI verte, sans conflit.

hermes-fusion referenced this pull request from a commit 2026-10-15 15:50:04 +02:00

Merge pull request 'Relevé : un délai et un journal par étape, et /etat porte « motif » (à afficher par le front Svelte)' (#1625) from hermes/releve-delai-etape into main

hermes-bot commented 2026-10-15 15:52:38 +02:00

Author

Collaborator

• Copy link
• Copy Markdown

Rebasé sur main (f79eca09) et poussé (214e764d). Un conflit : _tableau/LXC-132.md — les deux côtés ajoutaient une section en fin de fichier (la priorité du tableau côté main, le relevé des délais côté carte) : les deux apports sont gardés, aucun des deux n'est perdu.

Mesures locales : _tableau/front → 43/43 fichiers de banc, 370 essais verts ; npx vite build code 0, dist/index.html 1881 octets + 964K de JS. CI Forgejo : verte (run #597, 214e764d).

Un lien symbolique local _tableau/front/node_modules s'était glissé dans un commit pendant la résolution ; il a été retiré de la branche (history réécrite).

Rebasé sur `main` (f79eca09) et poussé (214e764d). Un conflit : `_tableau/LXC-132.md` — les deux côtés ajoutaient une section en fin de fichier (la priorité du tableau côté main, le relevé des délais côté carte) : les deux apports sont gardés, aucun des deux n'est perdu. Mesures locales : `_tableau/front` → 43/43 fichiers de banc, 370 essais verts ; `npx vite build` code 0, `dist/index.html` 1881 octets + 964K de JS. CI Forgejo : verte (run #597, 214e764d). Un lien symbolique local `_tableau/front/node_modules` s'était glissé dans un commit pendant la résolution ; il a été retiré de la branche (history réécrite).

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

ci-rouge

La CI de la PR est rouge : pas de fusion automatique

  

conflit

La PR est en conflit avec main : à rebaser

  

operateur

Cas sensible : seul l operateur fusionne

  

relu

Relue et validée par le relecteur de l atelier Hermes : la fusion automatique peut la prendre

No labels

ci-rouge

conflit

operateur

relu

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

foXaCe/studio!1625

No description provided.