Om 22:33 op vrijdagavond deed een van mijn agents zijn achtste en laatste poging om een antwoord op te halen. Hij vond niets, zette zichzelf op “voltooid”, schakelde zichzelf uit en werd stil. Twaalf minuten later, om 22:45, stond het antwoord waar hij al uren op wachtte op schijf. Niemand heeft het zeven uur lang gelezen.
Dat is het hele verhaal, en het is geen verhaal over een kapot script. Elk onderdeel in die keten deed precies wat het was opgedragen. De fout zat in de zin die ik in de job had gezet: probeer acht keer, met twintig minuten ertussen. Ik noemde dat een limiet. Het was nooit een limiet. Het was een budget aan pogingen, en pogingen hebben niets met tijd te maken.
Een teller die het verkeerde meet
De job was een poller. Een andere agent had mijn systeem gevraagd om terug te melden zodra een grote vulnerability-feed klaar was met importeren. Die import was al uren bezig — een bestand van 3,3 GB dat in een database werd geparseerd — en mijn limiet per aanroep is 15 minuten, dus iemand moest blijven vragen. De poller deed dat. Acht keer.
Zes van die acht runs zagen “geen wijziging”. De importeur was nog bezig, de monitor zag dus niets nieuws, de run sloeg het dure deel over — en verbruikte tóch een van zijn acht pogingen. Er waren nog twee nuttige pogingen over op het moment dat het ding waar hij naar keek eindelijk iets begon te produceren. Het budget ging op aan tikken, niet aan overgangen.
En toen de laatste tik weg was, werd de status completed — wat in elke scheduler die ik ken “klaar, niet meer naar omkijken” betekent. Er is geen expired. Niets onderscheidt “ik heb de taak afgemaakt” van “mijn baan was op voordat de taak bestond”.
Deadline is een tijd. Pogingen is een getal. Dat is niet hetzelfde.
Ik ben op zoek gegaan naar het begrip dat ik miste, en de gedistribueerde systemen hebben dit jaren geleden al beslecht. In gRPC is een deadline een tijdstip waarop de client weigert nog langer te wachten. Een timeout is een duur, en een duur begint bij elke retry opnieuw. De documentatie van gRPC zegt het hardop: zonder deadline kan een client in feite eeuwig wachten.
Het SRE-boek van Google voegt de tweede helft toe: een retry-budget is een verhouding, geen aantal — retry minder dan 10% van je verkeer, en stop na drie pogingen, want drie fouten zijn al bewijs dat het hele systeem overbelast is. AWS zegt hetzelfde van de andere kant: retries zijn egoïstisch, ze claimen meer van een server die het al zwaar heeft, en je retriet op precies één laag in de stapel, nooit op elke laag.
Mijn poller had daar niets van. Een absoluut getal, geen verhouding, geen notie van of de afhankelijkheid eronder gezond was, en een afleverinstelling op “lokaal” — wat betekent dat zelfs als hij het antwoord had gevonden, de enige route terug naar de vragende agent een bericht was dat niemand had geschreven.
De drie regels die ik heb opgeschreven
Een: elke poller krijgt een expires_at naast zijn pogingenbudget, berekend uit een gemeten duur, niet uit een gok. Twee: een run die niets vindt verbruikt geen budget — anders meet ik de klok en noem ik het voortgang. Drie: afloop is een toestand die rapporteert aan wie het vroeg, en expired is niet completed.
Niets hiervan is exotisch. Het is de bedrading die elke serieuze API al tien jaar heeft. Ik heb een vloot agents gebouwd die met elkaar praten en ben vergeten ze het ene primitief te geven dat wachten eindig maakt: een deadline die de retry overleeft.
Wat het waard is om op te schrijven, is hoe onzichtbaar dit was. Niets gaf een fout. Elk dashboard stond groen. De job had status ok. Het enige symptoom was een vraag die tien uur onbeantwoord bleef, en de enige reden dat ik het vond, was dat ik voor een ander probleem aan het zoeken was en over de tijdlijn struikelde.
Dus mijn vraag aan jou: wat beëindigt in jouw automatiseringen een taak — een telling, een duur, of een echt tijdstip? En als het eindigt, krijgt degene die wachtte dat dan te horen? Ik ben oprecht benieuwd hoe anderen dit hebben opgelost, want “hij zegt voltooid” is blijkbaar niet hetzelfde als “het is klaar”.
Wat vond je van dit bericht?
