Het artikel introduceert Transparent Continuation Checkpointing (TCC) als alternatief voor de traditionele methode van history replay bij duurzame executie. Waar history replay de huidige positie reconstrueert door alle bewaarde stappen opnieuw uit te voeren, slaat TCC de actieve voortzetting (de controlestatus) direct op.
De belangrijkste voordelen en bevindingen zijn:
- Efficiëntie: Hersteltijd is bij TCC afhankelijk van de grootte van de status, niet van de lengte van de executiegeschiedenis.
- Prestaties: In tests bleef de hersteltijd van TCC nagenoeg constant (0,6 - 0,9 ms), terwijl een baseline van Temporal toenam van 61 ms naar 1,7 s naarmate de diepte van de duurzame grens toenam.
- Toepassing: De auteur bouwt Trigora op basis van dit model, specifiek gericht op long-running AI-agents.
- Uitdagingen: Voor productiegebruik is er nog werk nodig op gebieden als versiebeheer, portable representatie en commit-protocollen.
Duurzame executie zonder history replay
Dit is een nuttig model. Het biedt duurzame voortgang terwijl workers efemerisch kunnen blijven. Het zorgt er echter ook voor dat de opgehoopte geschiedenis onderdeel wordt van het hersteltraject.
Deze afweging wordt merkbaarder bij programma's die uren of dagen draaien, veel tools aanroepen, wachten op externe gebeurtenissen, ondergeschikte executies (child executions) maken en dynamisch van richting veranderen. Long-running agents hebben steeds vaker deze vorm.
Ik heb een andere recovery-primitive gebouwd en geëvalueerd: het maken van checkpoints van de programmavoorzetting (continuation checkpointing) in plaats van deze te reconstrueren vanuit de geschiedenis.
Transparent Continuation Checkpointing
Ik noem deze aanpak Transparent Continuation Checkpointing, of TCC.
Bij duurzame grenzen (durable boundaries) leggen de compiler en de runtime de actieve voortzetting vast: de controlestatus die nodig is voor het programma om verder te gaan vanaf de huidige positie. Wanneer de executie wordt hervat na een storing, laadt de runtime de vastgelegde voortzetting en herstelt het programma direct.
Vergelijking:
- History replay: Reconstrueert de huidige positie.
- TCC: Herstelt de vastgelegde voortzetting en hervat de executie.
Het onderscheid is als volgt:
History replay Laad bewaarde geschiedenis → voer de prefix opnieuw uit → reconstrueer de huidige positie.
TCC Laad vastgelegde voortzetting → herstel actieve executiestatus → hervat.
Externe effecten blijven expliciete duurzame operaties. Voltooid duurzaam werk wordt na herstel niet herhaald, en niet-ondersteunde taalconstructies falen tijdens de compilatie in plaats van ambigu runtime-gedrag te produceren.
Het huidige prototype ondersteunt duurzame effecten, externe wachttijden en gebeurtenissen, ondergeschikte executies, annulering, gestructureerde concurrency en herstel na crashes.
Wat verandert er
TCC zorgt er niet voor dat herstel in constante tijd (constant-time) gebeurt. Herstel blijft gevoelig voor de grootte en structuur van de actieve voortzetting.
De beoogde verandering zit in waar het herstel van afhankelijk is.
Bij replay wordt herstel beïnvloed door de executiegeschiedenis die bewaard is om de huidige positie te reconstrueren. Bij TCC wordt herstel primair beïnvloed door de status die het programma nog nodig heeft.
Een programma dat tienduizend operaties heeft uitgevoerd, maar een kleine actieve voortzetting behoudt, zou niet noodzakelijkerwijs moeilijker te herstellen moeten worden, enkel omdat het verleden lang is.
Voorlopige evaluatie
Ik heb een gecontroleerde vergelijking uitgevoerd waarbij de actieve voortzettingstatus ongeveer constant bleef, terwijl de diepte van de duurzame grens (durable-boundary depth) toenam van 10 naar 1.000.
Hersteltijd (latency) versus diepte van de duurzame grens:
- TCC-herstel: Bleef tussen ongeveer 0,6 en 0,9 milliseconden.
- Temporele reconstructie (baseline): De reconstructie via een nieuwe worker in de geëvalueerde Temporal-baseline nam toe van ongeveer 61 milliseconden naar 1,7 seconden.
Bij deze evaluatie was de actieve status ongeveer 4 KB en is de creatie van de worker uitgesloten. Deze resultaten moeten niet worden geïnterpreteerd als een algemene claim over productiesnelheid. Ze tonen een verschil in de schaling van het herstel onder de geteste omstandigheden aan, niet dat elke TCC-workload beter zal presteren dan elk replay-gebaseerd systeem.
Methodologie en beperkingen
Ik heb de executiesemantiek daarnaast getest over 50.000 gegenereerde gevallen, waarbij geen semantische fouten zijn waargenomen in de geëvalueerde subset.
Wat blijft moeilijk
Om het prototype om te zetten in productie-infrastructuur is nog aanzienlijk werk nodig:
- Draagbare representatie van voortzettingen (portable continuation representation)
- Versiebeheer van programma's en checkpoints
- Efficiënte afhandeling van grotere actieve statussen
- Duurzame opslag en commit-protocollen
- Operationele observeerbaarheid
- Compatibiliteit tussen verschillende taalfrontends
- Integraties met frameworks
- Correctheidstesten en foutentesten voor langdurige processen
Er zijn ook ontwerpvragen over het bewaren van checkpoints, het vertakken vanuit vorige voortzettingen, migratie tussen runtime-versies en hoeveel van de executierepresentatie stabiel moet blijven over verschillende talen heen.
Ik bouw Trigora rond dit model, in eerste instantie voor long-running AI-agents. De bredere vraag is of herstel op basis van voortzettingen een betere executieonderlaag kan bieden voor dynamische, langdurige software.
Duurzame executie zonder history replay
Dit is een nuttig model. Het biedt duurzame voortgang terwijl workers efemerisch kunnen blijven. Het zorgt er echter ook voor dat de opgehoopte geschiedenis onderdeel wordt van het hersteltraject.
Deze afweging wordt merkbaarder bij programma's die uren of dagen draaien, veel tools aanroepen, wachten op externe gebeurtenissen, ondergeschikte executies (child executions) maken en dynamisch van richting veranderen. Long-running agents hebben steeds vaker deze vorm.
Ik heb een andere recovery-primitive gebouwd en geëvalueerd: het maken van checkpoints van de programmavoorzetting (continuation checkpointing) in plaats van deze te reconstrueren vanuit de geschiedenis.
Transparent Continuation Checkpointing
Ik noem deze aanpak Transparent Continuation Checkpointing, of TCC.
Bij duurzame grenzen (durable boundaries) leggen de compiler en de runtime de actieve voortzetting vast: de controlestatus die nodig is voor het programma om verder te gaan vanaf de huidige positie. Wanneer de executie wordt hervat na een storing, laadt de runtime de vastgelegde voortzetting en herstelt het programma direct.
Vergelijking:
- History replay: Reconstrueert de huidige positie.
- TCC: Herstelt de vastgelegde voortzetting en hervat de executie.
Het onderscheid is als volgt:
History replay Laad bewaarde geschiedenis → voer de prefix opnieuw uit → reconstrueer de huidige positie.
TCC Laad vastgelegde voortzetting → herstel actieve executiestatus → hervat.
Externe effecten blijven expliciete duurzame operaties. Voltooid duurzaam werk wordt na herstel niet herhaald, en niet-ondersteunde taalconstructies falen tijdens de compilatie in plaats van ambigu runtime-gedrag te produceren.
Het huidige prototype ondersteunt duurzame effecten, externe wachttijden en gebeurtenissen, ondergeschikte executies, annulering, gestructureerde concurrency en herstel na crashes.
Wat verandert er
TCC zorgt er niet voor dat herstel in constante tijd (constant-time) gebeurt. Herstel blijft gevoelig voor de grootte en structuur van de actieve voortzetting.
De beoogde verandering zit in waar het herstel van afhankelijk is.
Bij replay wordt herstel beïnvloed door de executiegeschiedenis die bewaard is om de huidige positie te reconstrueren. Bij TCC wordt herstel primair beïnvloed door de status die het programma nog nodig heeft.
Een programma dat tienduizend operaties heeft uitgevoerd, maar een kleine actieve voortzetting behoudt, zou niet noodzakelijkerwijs moeilijker te herstellen moeten worden, enkel omdat het verleden lang is.
Voorlopige evaluatie
Ik heb een gecontroleerde vergelijking uitgevoerd waarbij de actieve voortzettingstatus ongeveer constant bleef, terwijl de diepte van de duurzame grens (durable-boundary depth) toenam van 10 naar 1.000.
Hersteltijd (latency) versus diepte van de duurzame grens:
- TCC-herstel: Bleef tussen ongeveer 0,6 en 0,9 milliseconden.
- Temporele reconstructie (baseline): De reconstructie via een nieuwe worker in de geëvalueerde Temporal-baseline nam toe van ongeveer 61 milliseconden naar 1,7 seconden.
Bij deze evaluatie was de actieve status ongeveer 4 KB en is de creatie van de worker uitgesloten. Deze resultaten moeten niet worden geïnterpreteerd als een algemene claim over productiesnelheid. Ze tonen een verschil in de schaling van het herstel onder de geteste omstandigheden aan, niet dat elke TCC-workload beter zal presteren dan elk replay-gebaseerd systeem.
Methodologie en beperkingen
Ik heb de executiesemantiek daarnaast getest over 50.000 gegenereerde gevallen, waarbij geen semantische fouten zijn waargenomen in de geëvalueerde subset.
Wat blijft moeilijk
Om het prototype om te zetten in productie-infrastructuur is nog aanzienlijk werk nodig:
- Draagbare representatie van voortzettingen (portable continuation representation)
- Versiebeheer van programma's en checkpoints
- Efficiënte afhandeling van grotere actieve statussen
- Duurzame opslag en commit-protocollen
- Operationele observeerbaarheid
- Compatibiliteit tussen verschillende taalfrontends
- Integraties met frameworks
- Correctheidstesten en foutentesten voor langdurige processen
Er zijn ook ontwerpvragen over het bewaren van checkpoints, het vertakken vanuit vorige voortzettingen, migratie tussen runtime-versies en hoeveel van de executierepresentatie stabiel moet blijven over verschillende talen heen.
Ik bouw Trigora rond dit model, in eerste instantie voor long-running AI-agents. De bredere vraag is of herstel op basis van voortzettingen een betere executieonderlaag kan bieden voor dynamische, langdurige software.
Groetjes,