feat(order): expiration des commandes restees en attente de paiement #127
No reviewers
Labels
No labels
auto-merge
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
AcadeNice/corentin_wakdo!127
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/order-expire-pending"
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?
Le flux de commande fait DEUX appels HTTP : creation puis encaissement. La creation committe dans sa propre transaction, donc pending_payment est reellement observable entre les deux, et un echec du second appel (reseau coupe, borne redemarree, onglet ferme) laisse une commande complete et inerte. Elle ne bloque aucun stock, elle est exclue du chiffre d'affaires et de la file cuisine, mais elle reste comptee "en attente" sur le tableau de bord. OrderRepository::expireStalePending() passe ces commandes en cancelled avec une trace d'audit sans acteur (action_code order.expire). Appelee par le planificateur a 02h00 via src/bin/order-expire.php : apres la fermeture du service, avant le dump de 03h00, pour que la sauvegarde de la nuit contienne l'etat nettoye. Invariant central : AUCUNE ecriture sur ingredient ni stock_movement. Une commande en attente n'a rien consomme, la re-crediter creerait du stock a partir de rien. Deux tests le verrouillent, dont un contre la vraie base qui compare les quantites et le nombre de mouvements avant/apres. Choix consignes en ADR-0014 : - cancelled plutot qu'un statut expired (valeur deja terminale, deja exclue du CA, deja libellee "Annulee" a l'ecran ; la distinction vit dans le journal d'audit) et plutot qu'une suppression (qui detruirait la trace et pourrait detacher un mouvement de stock de sa commande via ON DELETE SET NULL) - le balayage est du code metier, pas du SQL dans un script : c'est une transition de la machine a etats et les cinq autres vivent dans OrderRepository. L'image du planificateur gagne donc PHP en ligne de commande -- ce que PROJECT_CONTEXT decrivait DEJA ("Alpine + PHP CLI") alors que le Dockerfile ne l'avait pas. Une transaction par commande (une ligne problematique ne fait pas perdre le balayage), garde de statut dans le WHERE comme pay et cancel, valeurs de INTERVAL et LIMIT bornees en entier avant interpolation (aucun parametre lie possible en prepare native). Documentation du cycle de vie realignee sur le code : docs/uml/state-commande.md decrivait une machine a 4 etats et affirmait preparing/ready supprimes et pending_payment non observable -- les trois affirmations etaient devenues fausses. Reecrit avec les 6 valeurs reelles et les 6 transitions ancrees methode par methode, dont le fait que le statut paid n'est plus ecrit par aucun code depuis le passage au paiement-met-en-preparation. mlt.md gagne la section 13.6 et voit sa section 14 corrigee. Le dictionnaire, le MLD et le MCD restent en ecart : dette signalee, traitee a part. Corrections adjacentes du meme cycle de vie : la page de confirmation d'annulation n'avait pas de libelle pour preparing/ready (elle affichait la valeur brute) et refusait l'annulation dans ces etats alors que la liste proposait le lien et que le domaine les accepte. Un commentaire de cancel() annoncait une garde incomplete. 521 tests unitaires (+9) et 59 d'integration (+7) verts, PHPStan L6 propre. Image du planificateur construite et point d'entree execute pour de vrai contre la base en service. Etape production a reporter a la main : voir ADR-0014.