En butik, der sendte ordrebekræftelser på SMS, begyndte at få klager, der først var smigrende og siden dyre: kunderne fik den samme bekræftelse fire eller fem gange. Beskeden var korrekt. Der var bare for mange af dem, og hver eneste kostede penge.
Hooket var fejlen
Afsendelseskoden var koblet på et filter, der kører, mens takkesiden vises. Filtre af den slags er ikke et løfte om, at noget skete én gang; de kører, hver gang siden bygges. En genindlæsning af bekræftelsessiden, at navigere frem og tilbage eller en browser, der henter URL’en på forhånd, gav hver en ny visning, og hver visning sendte en ny besked.
Det er en generel fælde og ikke en særegenhed ved ét plugin. Et hook, der kører under visning, svarer på spørgsmålet “hvad skal siden vise”. Bivirkninger, der koster penge eller rører omverdenen, hører hjemme på hooks, der svarer på “hvad er der lige sket”.
To ændringer, ikke én
Afsendelsen blev flyttet til en action, der svarer til, at ordren faktisk afgives. Det alene mindsker problemet, men fjerner det ikke, fordi genforsøg, race conditions og samspil med plugins stadig kan levere den samme hændelse to gange.
Derfor registrerer ordren nu selv, at dens besked er sendt. Afsendelsen tjekker først det flag og stopper straks, hvis det er sat. Ordren er det eneste, der består på tværs af alle forespørgsler, hvilket gør den til det rigtige sted at gemme svaret på “har vi allerede gjort det?”
Fejl stille i den rigtige retning
Hvis SMS-adgangsoplysningerne mangler eller telefonnummeret er tomt, stopper funktionen uden at sende og uden at give en fejl, der ville blokere ordren. En bekræftelsesbesked, der fejler, må aldrig forhindre et salg i at blive gennemført; ordren er det, der betyder noget, og notifikationen er en bekvemmelighed oven i.
Det vigtigste
- Visningshooks kører gentagne gange. Læg aldrig bivirkninger, der koster penge, på dem.
- At flytte til det rigtige hook mindsker dubletter; et idempotens-flag fjerner dem.
- Gem flaget på selve posten, ikke i en session eller en transient.
- Fejl i notifikationer bør nedtrappes stille og aldrig blokere transaktionen.
Læs også: manuelle betalinger med mobile penge, og hvorfor ordremails ikke nåede frem til Gmail.
Støder du på en lignende begrænsning i din egen WooCommerce- eller WordPress-butik? Lad os tale — ArtinTech Solution bygger netop den slags skræddersyede værktøjer til webshops.