File d'envoi
L'écran /envois/file montre ce qui attend d'être posté. C'est l'autre bout du temps par
rapport à Envois, qui montre ce qui est parti.
Les deux lisent deux sources différentes, et c'est toute la raison d'être de cette page : une ligne d'historique naît au moment où l'envoyeur poste. Un essai lancé en cadence chronologique pour demain ne laisse donc rien en base avant sa première échéance — et mille lots parfaitement en ordre se lisent alors comme un envoi qui n'a jamais eu lieu.
On y accède depuis la section Débug de la barre de navigation — qui regroupe les écrans d'observation, par opposition à ceux qui configurent le produit —, depuis la ligne « lots en file » de l'écran des envois, et depuis la carte « File d'envoi » du dashboard.
Quatre états, et pas un cinquième
| État | Sens |
|---|---|
| Différés | Programmés pour plus tard — la cadence chronologique et le rejeu en direct |
| En attente | Mûrs, ils partent dès qu'un envoyeur est libre |
| En cours | En cours de POST vers l'intake |
| En échec | Refusés définitivement, après cinq tentatives ou sur une erreur qui ne se retente pas |
Les lots terminés n'y figurent pas, et c'est délibéré : ils ont laissé une ligne d'historique, que l'écran des envois tient depuis la base avec son issue, sa durée et ses messages conservés 24 h. Les relire ici depuis Redis — qui n'en garde que cent, une heure durant — ferait deux écrans qui se contredisent sur le même envoi.
Un lot en cours n'est jamais purgeable : sa requête HTTP est déjà partie, et le retirer de la file ne l'annulerait pas. L'offrir ferait un bouton qui ment.
Ce que le tri classe, et ce qu'il ne classe pas
Le tri porte sur l'ordre naturel de l'état regardé — l'échéance pour les différés, le rang pour l'attente, l'instant de l'échec pour les échecs — et s'inverse d'un clic sur l'en-tête.
Il n'y a pas de tri par destination, par technologie ni par nombre de messages, et pas de filtre par source, banc, communauté ou technologie. La raison est la même dans les deux cas : un lot porte ses messages déjà rendus, et rien dans la file ne permet de lire ses métadonnées sans sa charge utile. Filtrer ou trier sur autre chose obligerait à charger toute la file à chaque affichage de page — des dizaines de méga-octets pour vingt-cinq lignes.
Chaque ligne nomme sa source — la pastille colorée même des Envois, si bien qu'un lot ne change pas de couleur en quittant la file : Flux normal, Scénario de menace, Banc d'essai ou Envoi manuel, suivie de sa communauté, de son scénario ou de son banc — et sa technologie : c'est le filtre global qui manque, pas l'information. Et la purge, elle, accepte le filtre — c'est un geste délibéré et confirmé, pas un rendu de page.
Déplier un lot
Chaque ligne se déroule sur ce que le lot s'apprête à poster — au passé pour un lot en échec, qui a déjà essayé. C'est ce qui manquait le plus : jusque-là, on ne pouvait relire un message qu'après son envoi.
Le plafond est le même que celui des envois passés — cent messages —, et le panneau annonce le total : « les 100 premiers messages sur 1 000 ». Rien n'est tronqué en silence.
La fiche du lot nomme son identifiant, son échéance, sa source, et d'où sa clé d'intake sera lue — jamais la clé. Le dire vaut mieux que l'omettre : « lue sur le banc à l'envoi » ou « lue sur la communauté à l'envoi » explique pourquoi un lot différé peut échouer des heures plus tard sur une clé effacée entre-temps.
Le dépliage fonctionne sans JavaScript : le contrôle est un lien qui pose la ligne ouverte dans
l'URL (?ouvert=…), et la page revient avec le panneau rendu. L'écran reste donc partageable.
Retirer
Quatre gestes, du plus fin au plus large :
- une ligne ou une sélection — les cases du tableau, puis « Retirer la sélection » ;
- un état entier — « Supprimer les lots différés », en deux temps ;
- toute la file — différés, en attente et en échec ; les lots en cours d'envoi ne sont pas concernés, et le bouton le dit ;
- les lots d'un banc — depuis la page du banc, « Annuler les envois programmés ».
Ce dernier et la purge par état sont le même geste, filtré : une seconde implémentation finirait par ne plus retirer la même chose que la première, et deux boutons annonceraient deux comptes pour le même travail.
Le compte rendu porte ce qui a réellement été retiré, détaillé par état — un total seul ne dirait pas si les échecs ont été emportés. Il peut être inférieur à ce qui était demandé, et ce n'est pas une erreur : deux onglets ouverts sur la même file, et l'un purge ce que l'autre proposait encore.
La confirmation d'une purge de masse passe par l'URL (?supprimer=…) plutôt que par une boîte de
dialogue : confirm() n'existe pas sans JavaScript, et le parcours sans JS est un acquis du projet.
Suspendre
« Suspendre la file » arrête la prise en charge : plus aucun envoyeur ne prend de lot. Rien n'est perdu ni déplacé — les lots restent où ils sont, les compteurs restent justes, et ce qui était déjà parti termine son aller-retour.
L'écran l'annonce en bandeau, et il le doit : une file en pause qui ne le dirait pas se lirait comme une panne — les lots s'empilent, rien ne part, et l'écran des envois reste muet.
Rejouer un échec
Un lot en échec se rejoue depuis son panneau. Il repart en attente, tentatives remises à zéro : c'est le geste qui manque quand l'intake a été indisponible et qu'il l'est de nouveau.
Temps réel
La page se met à jour d'elle-même à chaque envoi terminé — c'est précisément l'instant où la file change, puisqu'un lot la quitte. Le mécanisme est celui de l'écran des envois, et c'est le même flux : une annonce sert de signal pour relire les données, qui restent lues dans Redis. Une annonce perdue ne laisse donc jamais l'écran dans un état faux.