Wanneer een proces uit meerdere stappen mislukt, kan het opnieuw uitvoeren van het hele proces effecten herhalen die al hebben plaatsgevonden: twee bestellingen aanmaken, twee meldingen versturen of hetzelfde record twee keer importeren. Gedeeltelijk herstel van mislukte PHP-processen houdt in dat je bepaalt welke stappen zijn bevestigd, welke zonder risico opnieuw kunnen worden uitgevoerd en welke compensatie of menselijke beoordeling vereisen.
De beslissing hangt af van de semantiek van elke bewerking, niet alleen van de plek waar een exception optrad. Een verloren API-respons bewijst bijvoorbeeld niet dat het externe systeem het verzoek heeft afgewezen. Het proces kan zijn voltooid terwijl de verbinding uitviel voordat PHP het resultaat ontving. Door voor dit scenario te ontwerpen voorkom je dat een onderbroken uitvoering wordt verward met een uitvoering die nooit heeft plaatsgevonden.
Kiezen tussen opnieuw proberen, hervatten en compenseren
Een volledige nieuwe poging voert alle stappen opnieuw uit. Dit is geschikt wanneer de hele workflow idempotent is — herhaling resulteert in dezelfde eindstatus — of wanneer er nog geen externe effecten zijn opgetreden. Als geen van beide voorwaarden kan worden gegarandeerd, is herhaling zonder eerst te controleren riskant.
Hervatten betekent doorgaan vanaf de eerste stap die niet is bevestigd. Daarvoor moeten de status van de stappen en hun resultaten worden geregistreerd. Ook moet je het effect van een aanroep waarvan het resultaat ambigu is, kunnen achterhalen of verifiëren. Dit betekent niet dat je alles overslaat wat voltooid lijkt: daarvoor is opgeslagen bewijs nodig.
Compenseren betekent een actie uitvoeren die een eerder effect compenseert of tegenwerkt, zoals een reservering annuleren. Daarmee wordt de oorspronkelijke status niet altijd exact hersteld: een al verstuurde melding kan niet worden ingetrokken en voor een geïncasseerde betaling kan een terugbetaling nodig zijn, met een eigen verwerkingstermijn en registratie. Compensatie is daarom een expliciete bedrijfsbewerking, geen automatische rollback van de database.
Stappen modelleren met persistente statussen en resultaten
Modelleer de workflow als een reeks of state machine met stappen die stabiele namen, identificeerbare invoer en persistente resultaten hebben. Een eerste model kan statussen bevatten zoals pending, running, succeeded, retryable, failed en manual_review. Definieer de toegestane transities en voorkom dat een proces naar een eindstatus overgaat zonder het benodigde bewijs op te slaan.
Een record per proces kan een stabiele identifier bevatten, het type workflow, de globale status, de versie van de procesdefinitie, start- en wijzigingsdatums, de poging en de reden voor de laatste transitie. Elke stap moet de status, een bewerkingsidentifier, tijdstempels en een verwijzing naar het relevante resultaat opslaan. Bewaar alleen de informatie die nodig is om de uitvoering te hervatten of het resultaat toe te lichten; kopieer niet klakkeloos volledige API-responsen of secrets.
In PHP kan de orchestrator de statustransitie scheiden van de uitvoering van de stap. De update moet atomair zijn wanneer meerdere workers dezelfde taak kunnen claimen: gebruik een transactie of een passend lockmechanisme en registreer wie het proces heeft geclaimd en tot wanneer. Een lock met een vervaltijd moet het mogelijk maken verlaten taken te herstellen, zonder een onafgemaakte stap als voltooid te markeren.
Checkpoints definiëren zonder uit te gaan van ‘exactly once’
Sla na elk resultaat een checkpoint op dat het systeem betrouwbaar kan bevestigen. Voor lokale bewerkingen kan dit een transactie zijn die de bedrijfswijziging en de status van de stap samen opslaat. Voor een externe aanroep bestaat er geen gezamenlijke transactie tussen de database en de provider: het proces kan stoppen nadat de provider de bewerking heeft uitgevoerd, maar voordat PHP het antwoord registreert.
Gebruik op die grens een idempotency key als de provider die ondersteunt, afgeleid van een stabiele identifier van het proces en de stap. Als die ondersteuning ontbreekt, raadpleeg dan de externe status aan de hand van een bewerkingsidentifier voordat je het verzoek herhaalt. Als er noch idempotentie noch een betrouwbare raadpleging mogelijk is, behandel het resultaat dan als ambigu en stuur de zaak door voor beoordeling. Een timeout volstaat niet om te concluderen dat de bewerking niet heeft plaatsgevonden.
Voor asynchrone taken maakt het transactional outbox-pattern het mogelijk om de lokale wijziging en het wachtende bericht in één transactie op te slaan. Een worker bezorgt het bericht later; ook de consumer moet duplicaten aankunnen, bijvoorbeeld door verwerkte identifiers op te slaan. Deze mechanismen beperken inconsistenties, maar maken niet automatisch een volledige gedistribueerde integratie atomair.
Grenzen stellen aan heruitvoering en compensatie
Bepaal per stap welke fouten tijdelijk zijn, welke definitief zijn en welke een onbekend resultaat opleveren. Tijdelijke fouten kunnen nieuwe pogingen met oplopende wachttijden en willekeurige spreiding toelaten; stel een maximumaantal pogingen en een totale termijn vast. Validatie- of permissiefouten worden doorgaans niet opgelost door opnieuw te proberen: stop de workflow, verhelp de oorzaak en bepaal of een nieuwe uitvoering passend is.
Leg voor elk extern effect vast of het opnieuw kan worden uitgevoerd, geraadpleegd, gecompenseerd of niet kan worden teruggedraaid. Behoud het resultaat wanneer de bewerking geldig is en herhaling schadelijker zou zijn dan de gedeeltelijke status; compenseer alleen als er een veilige en geautoriseerde bedrijfsactie bestaat. Stop en schaal op wanneer de gegevens niet volstaan om vast te stellen wat er is gebeurd, de compensatie ook mislukt of de actie financiële, juridische of klantimpact heeft waarvoor goedkeuring nodig is.
Een compensatiebeleid moet de volgorde, voorwaarden, verantwoordelijke en verwachte uitkomst specificeren. Registreer de compensatie als een nieuwe stap, gekoppeld aan het oorspronkelijke effect, in plaats van de geschiedenis ervan te verwijderen. Zo kan Operations onderscheid maken tussen een actie die nooit is uitgevoerd, een uitgevoerde actie en een actie die is gecompenseerd.
Operations voorzien van controles en context om te handelen
De console of operationele procedure moet de globale status en de status per stap tonen, de laatst geclassificeerde fout, het aantal pogingen, externe referenties en de toegestane actie. Bied geen generieke knop ‘alles opnieuw proberen’ aan. Toon afgebakende opties: een idempotente stap opnieuw proberen, de externe status raadplegen, een compensatie uitvoeren of escaleren.
Beveilig deze acties met autorisatie op basis van rollen; vraag om aanvullende bevestiging voor gevoelige effecten en registreer wie wanneer handelde, wat diegene koos en waarom. Als heruitvoering de invoergegevens wijzigt, verplicht dan een nieuwe uitvoering of een expliciete herziening in plaats van de invoer van een historisch proces stilzwijgend aan te passen.
Bewaar voor diagnose zonder gevoelige informatie bloot te leggen correlatie-identifiers, foutcodes, de procesversie en referenties die nodig zijn om bronsystemen te raadplegen. Redigeer tokens, persoonsgegevens en volledige payloads. Bepaal ook hoelang logs worden bewaard en wie ze mag raadplegen. Een bruikbare trace legt uit wat er is gebeurd zonder een onnodige kopie van de bedrijfsgegevens te worden.
Storingen testen en herstel geleidelijk uitrollen
Test onderbrekingen op concrete punten: vóór de uitvoering van een stap, nadat de provider heeft gehandeld maar vóór het antwoord is opgeslagen, tijdens een compensatie en terwijl twee workers hetzelfde proces proberen te claimen. Controleer voor elk scenario of de status consistent is, effecten niet worden gedupliceerd en handmatige acties worden geaudit.
Neem tests op voor ambigue antwoorden, herhaalde idempotency keys, ongeldige gegevens, limieten voor nieuwe pogingen en wijzigingen in de workflowversie. Integratietests met gesimuleerde afhankelijkheden kunnen gecontroleerde fouten reproduceren; wanneer de echte provider zich anders gedraagt, valideer dan ook het contract en de raadpleegmechanismen in een geschikte omgeving.
Begin bij een bestaande workflow met het classificeren van de stappen op basis van omkeerbaarheid en idempotentie. Sla daarna de status van een beperkte fase persistent op, implementeer herstel voor de risicovolste fouten en observeer openstaande gevallen voordat je de reikwijdte uitbreidt. Verwijder of reset geen historische records om de uitrol te vereenvoudigen: behoud de traceerbaarheid en bepaal hoe processen die met eerdere versies zijn aangemaakt, moeten worden geïnterpreteerd.
Checklist voor het implementeren van herstel
- Heeft elke stap identificeerbare invoer, een persistente status en een verifieerbaar resultaat?
- Is bekend welke aanroepen idempotent zijn en wat er moet gebeuren als hun resultaat ambigu is?
- Zijn er limieten voor pogingen, termijnen en foutclassificatie?
- Zijn compensaties gedefinieerd als bedrijfsacties, met audittrail en verantwoordelijke?
- Kan Operations raadplegen en handelen met de juiste rechten, zonder toegang tot onnodige gegevens?
- Zijn storingen tussen stappen, concurrency, heruitvoeringen en mislukte compensaties getest?
- Bestaat er een escalatieprocedure voor situaties waarin automatisch hervatten niet veilig is?
Het praktische uitgangspunt is dat je voldoende bewijs bewaart om de volgende stap te bepalen en de automatisering stopt wanneer dat bewijs tekortschiet. Veilig herstel probeert niet te verbergen dat er een fout is opgetreden: het maakt expliciet wat is voltooid, wat nog openstaat en wie het kan oplossen.
