STUD-1157 — relayer POST /api/erreurs-page vers le service Rust (serveur_processus.py) #1661
Loading…
Reference in a new issue
No description provided.
Delete branch "hermes/stud-1157-relais-erreurs-page"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Carte
t_3dd7c9c0. Le relais du serveur Python (8080) versservice-tableau(127.0.0.1:8096) ne servait que des GET.Cause, mesurée avant le correctif (le 14/10, par import et par requête) :
do_POSTretombait surrecevoir_actualiser, qui rend 404 à tout chemin hors/actualiser*. L'erreur JS de la page n'atteignait donc jamais le journal, et le.catch(() => {})du front l'avalait en silence.Remède —
_tableau/serveur_processus.py:concerne_post(chemin): liste blanche d'un chemin (/api/erreurs-page), pas de relais ouvert ;recevoir_erreur_page(): corps relu borné (CORPS_MAX, 64 Ko), relayé tel quel au service, réponse reprise telle quelle (code, corps, type) ; service injoignable : le même 502 qui dit pourquoi que le relais GET ;_tableau/serveur.py: la route est branchée dansdo_POST, juste avant le repli surrecevoir_actualiser; l'entrée reste derrière la session (do_POSTvérifie déjà le cookie) ;POST /api/processus/signalern'est pas touché (décision du 13/10), et les gestes de l'Atelier gardent leur propre relais.Banc —
_tableau/test_serveur_processus.pyétendu : relais borné, refus du service repris tel quel, routes hors liste non relayées, service muet en 502, en-têtes tordus sans exception. Rejoué sur le code d'avant :AttributeError: module 'serveur_processus' has no attribute 'concerne_post'— la panne, reproduite.Porte —
python3 _tableau/lancer-tests.py --sans-couverture: 160 bancs verts, code 0.garde_fous.py: rien à redire, code 0.API — aucune route ni aucun champ du service Rust ne change ici. Côté serveur Python (8080),
POST /api/erreurs-pagecesse de rendre 404 : le front Svelte (front/src/lib/erreurs-navigateur.js, carte voisine) verra enfin son envoi arriver au journal. À signaler àsvelte.Doc : section datée STUD-1157 en fin de
_tableau/LXC-132.md. Rien fusionné, rien déployé sur le 132.Cause : le relais du serveur Python vers service-tableau ne servait que des GET. `serveur_processus.concerne('/api/erreurs-page')` rendait False et le POST retombait sur `recevoir_actualiser`, qui répond 404 à tout chemin hors `/actualiser*`. Mesuré le 14/10 : POST /api/erreurs-page → 404, rien reçu par le service, et le `.catch(() => {})` du front avalait l'erreur en silence. Remède : `serveur_processus.concerne_post` (liste blanche d'un chemin) et `recevoir_erreur_page` relaient le POST au service — corps relu borné (CORPS_MAX, 64 Ko), réponse reprise telle quelle (code, corps, type). La route est branchée dans `do_POST` de serveur.py avant le repli sur `recevoir_actualiser` ; elle reste derrière la session. Service injoignable : le même 502 qui dit pourquoi que le relais GET. Ni repli Python ni journal local : une seule écriture, celle du service. Banc : `test_serveur_processus.py` étendu (relais borné, refus du service repris tel quel, routes hors liste non relayées, service muet en 502) — il échoue sur le code d'avant, où `concerne_post` n'existe pas. Doc : section STUD-1157 en fin de `_tableau/LXC-132.md`.988471e027b609fa4a41b609fa4a411daf7a9df7Le relais
GET /api/erreurs-pageest livré (même branche, même PR)Tête :
1daf7a9d, rebasé surhttpforge/main=a49cd411. Un seul commit ajouté ;e6479410(le relais POST) ne bouge pas.Ce qui change
_tableau/serveur_processus.py:/api/erreurs-pageentre dans la liste blanche des chemins relayés en GET (concerne), à côté de/api/processus,/api/calendrieret/api/accueil. Aucune logique recopiée :Processus.processusrelaie déjà et rend le 502 qui dit pourquoi quand le service est muet.POST /api/erreurs-pageest la seule écriture de cette liste (concerne_post),GET /api/erreurs-pageest relayé comme les autres JSON. Le « deux adresses » de l'intro devient « les adresses ci-dessous » (la liste en porte cinq)._tableau/LXC-132.md: section STUD-1157 complétée du GET (deux lignes de tableau, trois puces). Aucune autre section touchée._tableau/serveur.pyau-delà du branchement déjà fait, ni le front, ni/api/processus/signaler.La panne, mesurée avant / après
Avant (code d'avant le correctif, le même montage que le banc) :
Après :
Le banc neuf échoue sur le code d'avant :
Banc et suite
Cas neufs :
concerne('/api/erreurs-page')vrai ; un voisin n'est pas relayé (/api/erreurs-page/x,/api/erreurs-pages,/api/erreurs,/api/processus/signaler) ; le GET relayé reprend la réponse du service telle quelle (code, corps octet pour octet, type) et le service l'a bien vue passer ; service muet, le 502 dont l'erreur dit « injoignable », comme les trois autres JSON.CI (pc-studio, workflow
tableau.yml)Journal de la branche
Ce que je n'ai PAS mesuré
service-tableauici) : le relais se mesure contre un service de banc, jamais contre le vrai.GET /api/erreurs-pagen'est pas dans cette branche (elle est surhermes/stud-1157-backend-erreurs,ab165f74). Le relais Python est prêt ; ce que rend le service déployé aujourd'hui, je ne l'ai pas interrogé.Relecture — verdict : « Relu, conforme » (8/10). Étiquette
reluposée. Je ne fusionne pas.Commandes rejouées par moi sur le PC, arbre dédié (jamais la copie principale) :
git worktree add ~/atelier-hermes/wt/t_c44db485 hermes/stud-1157-relais-erreurs-page(+ un arbre détaché surhttpforge/main=a49cd411).La panne d'avant est reproduite.
Sur
httpforge/main(a49cd411) :concerne('/api/erreurs-page')→False,concerne_postabsent,POST /api/erreurs-page→404 text/plain « Not Found », rien vu du service.Sur la branche (
1daf7a9d) :concerne→True,concerne_post→True,POST→201 application/json, le service reçoit 50 octets sur/api/erreurs-page. Le GET aussi :404avant,200 application/jsonavec le corps du service tel quel après.Liste blanche, pas relais ouvert.
POST /api/erreurs-pageseul :/api/erreurs-page/x,/api/erreurs-pages,/api/processus,/api/ailleurs,/actualiser,/reglages,/retour,/cadencerestent servis par Python, le service n'en voit aucun./api/processus/signalerreste servi par Python (403, en-tête X-Retour manquant) : la décision du 13/10 « une seule écriture » tient. Les quatre gestes de l'Atelier gardent leur relais d'avant (ECRITURES), rien de neuf. La route est derrière la session : sans cookie,401et rien au service.concerne_postn'est vrai que pour le chemin exact (?x=1passe par le même chemin, la requête est retirée comme dans le relais GET).Bornes, mesurées.
Corps de 100 015 octets → le service reçoit exactement
CORPS_MAX= 65 536 octets, réponse201reprise. Refus du service (422 text/plain; charset=latin-1) repris tel quel : code, corps et type identiques. Service muet →502 application/json, corps{"erreur": "service-tableau injoignable : [Errno 111] Connection refused"}, jamais un 200 trompeur. Le corps est lu borné sans exception surContent-Lengthabsent, illisible ou négatif.Banc.
python3 _tableau/test_serveur_processus.py→ code 0. Rejoué sur le code d'avant : code 1,AttributeError: module 'serveur_processus' has no attribute 'concerne_post'(ligne 270) : le banc reproduit bien la panne.python3 _tableau/lancer-tests.py --sans-couverture→ 162 bancs verts, code 0, sur la branche comme surmain: aucun échec préexistant.python3 _tableau/garde_fous.py→ code 0, rien à redire.Propreté.
Base
httpforge/main=a49cd411, diff4 fichiers, +233/-8(serveur_processus.py,serveur.py,test_serveur_processus.py,LXC-132.md), 0 fichier front, 0 emoji, 0 base64, 0 secret. Deux commits, messages français, sans co-auteur. Branche poussée (1daf7a9d, identique au distant). PR ouverte parhermes-bot, CI pc-studio verte 4/4 sur1daf7a9d. Rien fusionné, rien déployé (un seul workflow,tableau.yml, tests seulement).Deux remarques (elles ne bloquent pas la livraison) :
front/src/lib/erreurs-navigateur.js(docstring derecevoir_erreur_pageet ligne 2061 deLXC-132.md), n'existe sur aucune branche : le fichier livré par la carte de la capture est_tableau/front/src/lib/capture-erreurs.js.urllib.request.urlopen), contrairement aux gestes de l'Atelier (_SansRedirection). Sans effet aujourd'hui : la route Rust de la PR #1642 rend200,400,429ou500, jamais de renvoi.Ce que je n'ai PAS mesuré : le vrai service-tableau du 132 et son journal (
/opt/studio/journaux/erreurs-page.jsonl), injoignables d'ici — le relais a été mesuré contre un service de banc ; la rotation du journal passés 4 Mo ; la route Rust, absente de cette branche (PR #1642, encore ouverte).Point de collision :
_tableau/serveur_processus.pyest aussi touché par la PR #1650 (régions différentes :NOM_ERREURSetrecevoir_signalement) ; le rebasage de #1650 surmainest en échec aujourd'hui (mergeable=false).Fusionnée automatiquement par
fusion-auto(forge) : CI verte (Rust et Front Svelte), PR relue (étiquetterelu), sans conflit.