Seks regler for en synkronisering som kjører mens ingen ser på

Den 8. oktober 2026 publiserte Lance Martin og CJ Avilla en gjennomgang av en agent som hver morgen leser Slack og GitHub og poster et sammendrag i Slack. Ingen ser den kjøre. Det mest nyttige avsnittet deres handler om en feil som ser ut som suksess. Når en kildes server er nede eller tokenet har utløpt, «ser agenten ingenting fra den kilden og rapporterer ‹ingenting nytt›».

En kontaktsynkronisering fra Shopify til Brevo har den samme feilen. Det har også alle planlagte synkroniseringer mellom to SaaS-verktøy. En lesing som feiler i stillhet, ser akkurat ut som en butikk der ingen har registrert seg i dag.

Artikkelen deres slutter med seks regler for en agent som kjører uten tilsyn. Les dem som en som driver synkroniseringer, og hver av dem er en regel for reverse ETL. Workeren døde. Synkroniseringen gjorde det ikke. følger én kontakt gjennom et krasj. Denne siden er sjekklisten over den: seks regler for en automatisert datasynkronisering, hva Tajos runner gjør med hver av dem i dag, og hvor den kommer til kort. Runnerens side er beskrevet i Gjenopprett en synkronisering som har hengt seg opp eller feilet.

1. Les fra et bokmerke, og flytt det først når batchen har landet

Den første regelen deres: «Les hver kilde fra et bokmerke, ikke fra et fast tidsvindu.» Et vindu på «de siste 24 timene» etterlater et hull når en kjøring starter sent, og gjentar poster når den starter tidlig.

En Tajo-synkronisering leser kilden sin i batcher fra en lagret markør. Markøren flytter seg på slutten av en batch, og bare når hver post i den batchen har landet. En kjøring som feiler, beholder den siste rene posisjonen, så neste kjøring leser den avbrutte batchen på nytt i stedet for å hoppe over den.

Ordrer får et eget bokmerke. En planlagt synkronisering av Shopify-ordrer starter ved sin første planlagte kjøring og sender det som har endret seg siden den forrige. Eldre ordrer sendes bare når en person kjører synkroniseringen. Planlagte kjøringer og kjøringer en person starter, har hver sin markør, så en innlasting av historikk eller en testbatch ikke kan spole den planlagte tilbake.

Prisen er at en avbrutt batch leses to ganger. Regel 2 er det som gjør det trygt.

2. Gi hver skriving en nøkkel som overlever krasjet

Den fjerde regelen deres teller et innlegg som sendt først «når Slack bekrefter det», og oppdaterer først da bokmerket og ledgeren. Et rekommandert brev fungerer slik. Det er levert når den signerte kvitteringen kommer tilbake, ikke når det forlater skranken.

Før Tajo skriver en post, får posten en leveringsnøkkel. Nøkkelen er en hash av synkroniseringen, kilden, sidemarkøren, posisjonen på siden og selve posten, så den inneholder ingen personopplysninger. Den reserveres før destinasjonen kalles, og merkes som fullført når skrivingen lykkes. Fullførte nøkler beholdes i sju dager. Et nytt forsøk, eller en senere planlagt kjøring, utleder den samme nøkkelen for den samme posten, finner den fullført og kaller ikke destinasjonen igjen.

Det har to kostnader. Etter sju dager glemmer ledgeren, og en ny avspilling fra en eldre markør kan skrive på nytt. Og en skriving som får tidsavbrudd, etterlater en ærlig tvil: Det andre systemet kan ha lagret den uten å svare. Tajo prøver den skrivingen igjen ved et senere forsøk i stedet for å registrere den som feilet i sju dager. En connector som gir destinasjonen sin egen idempotensnøkkel, fjerner den tvilen. En som ikke kan det, sitter igjen med muligheten for ett duplikat.

3. Én kjøring eier synkroniseringen og beviser det før hver skriving

Den tredje regelen deres: «Sjekk hvert element på nytt rett før du poster.» For en synkronisering er det som oftest har endret seg mellom lesing og skriving, hvem som har lov til å skrive.

Hver Tajo-synkronisering har én lease, med eget token og en levetid på 15 minutter som fornyes hvert femte minutt. En kjøring sjekker at den fortsatt har leasen før den kaller destinasjonen, og igjen før den flytter markøren. En kjøring som har mistet den, stopper, og siden dens viser «Kjøringen mistet plassen sin underveis og stoppet for å unngå å skrive to ganger.» En ny kjøring som kolliderer med en pågående, avsluttes i stedet for å stille seg i kø bak den.

Postene sjekkes også. Mellom lesing og skriving går postene gjennom samtykkefilteret. En kontakt som ville blitt skrevet til en markedsføringsmålgruppe uten dokumenterbart samtykke, avvises i stedet for å bli gjettet. Med hjelpesidens ord er feilmodusen «for forsiktig», aldri «sendt for mye».

4. Prøv på nytt det som går over, stopp det som varer

De seks reglene deres sier ingenting om hvor ofte man skal prøve igjen. En synkronisering trenger den regelen, fordi de vanligste feilene er en rate limit og et dårlig minutt hos en leverandør.

En Tajo-kjøring i kø som feiler, får fem forsøk. Ventetidene mellom dem er 60, 120, 240 og 480 sekunder, omtrent et kvarter til sammen. Noen feil prøves aldri på nytt, fordi et nytt forsøk ikke kan rette dem. En kjøring som kolliderte med en kjøring som allerede pågikk, prøves ikke på nytt, og heller ikke en kjøring der den publiserte versjonen eller tilkoblingene ikke lenger er gyldige.

En rekke er noe annet enn et uhell. Hvis de siste fem fullførte kjøringene siden synkroniseringen sist ble endret, alle feilet, setter Tajo synkroniseringen på pause og viser den siste feilen på siden dens. Én suksess nullstiller tellingen. Ingenting starter en pauset synkronisering på nytt av seg selv; en person retter årsaken og publiserer den på nytt. Artikkelen om den døde workeren forteller om hendelsen som ga denne regelen.

5. Behandle stillhet som et funn

«Rapporter en feilet lesing som uleselig, aldri som en rolig dag.» Dette er den vanskeligste av de seks, og den vi bare delvis oppfyller.

Der den holder: En lesing som gir feil, får kjøringen til å feile. Et avvist token eller en server som ikke svarer, sender ingenting til destinasjonen, lar markøren bli der den var og teller mot pausen etter fem feilede kjøringer. Og hver time, 13 minutter over, sjekker Tajo hvert arbeidsområde med en aktiv synkronisering. Den varsler sitt eget team når det ikke har vært noen vellykket kjøring de siste 24 timene, også for et arbeidsområde der ingen kjøring er registrert i det hele tatt. Det er timesjekken.

Der den ikke holder: Den stille lesingen forfatterne beskriver, er en lesing som svarer «OK» uten poster. Runneren vår teller det som en suksess. For kilder som Shopify-kunder varsler en egen sjekk Tajos team etter ti vellykkede kjøringer på rad med null poster, hvis synkroniseringen har levert poster før. Shopify-ordrer leses etter oppdateringstidspunkt, så en tom kjøring er normal der, og den sjekken kjører ikke. En kilde som returnerer noen poster, men færre enn den burde, blir ikke oppdaget i det hele tatt.

Innvendingen lyder slik: «Ti tomme kjøringer er to og en halv time med en plan på 15 minutter. Hvorfor ikke varsle ved den første?» Kontaktsynkroniseringer kjører som standard hvert 15. minutt. Og en butikk uten nye kunder på et kvarter er helt vanlig. Et varsel ved den første tomme kjøringen ville gått hver natt, og et varsel som alltid går, er et varsel ingen leser. Den grensen bytter fart mot troverdighet. Den er fortsatt en gjetning om stillhet, ikke forfatternes regel.

6. Bestem én gang hva synkroniseringen kan skrive, og la hver kjøring bevise det

Den femte regelen deres henter agentens preferanser «fra et lager agenten ikke kan redigere». Den sjette gir agenten lesetilgang overalt der den bare leser, og setter et tak på hva hver kjøring kan bruke. Begge finnes fordi agenten leser tekst andre har skrevet, og den teksten kan prøve å gi den ordrer.

Synkroniseringens versjon av preferansefilen er den publiserte regelen. Å publisere en Tajo-synkronisering binder den til en digest av nøyaktig den regelen som ble forhåndsvist. Å redigere den setter den tilbake til utkast, og den går gjennom forhåndsvisningen igjen før den kjører på nytt. Hver kjøring sjekker, før den endrer noe, at den kjører akkurat den publiserte versjonen med tilkoblingene den ble publisert med. En kjøring som ikke består den sjekken, prøves ikke på nytt. Retningen er også fast: En synkroniseringsregel skriver én vei og aldri tilbake til Shopify.

Kostnadstaket har ikke noe motstykke. Synkroniseringskjøringene våre har ingen kostnadsgrense per kjøring. Grensen for nye forsøk og pausen begrenser hvor lenge en feil kan vare, ikke hva en kjøring koster.

Hva som er bygget, og hva som ikke er det

Bygget, når dette skrives:

• En markør som først flytter seg etter en batch der hver post har landet, og en planlagt ordremarkør som kjøringer startet av en person ikke kan spole tilbake.
• En leveringsnøkkel per post, sjekket mot en ledger over fullførte skrivinger som beholdes i sju dager.
• Én lease per synkronisering, sjekket før skrivingen og før markøren flytter seg.
• Fem forsøk per kjøring, med 60 sekunders ventetid og deretter 120, 240 og 480, uten nytt forsøk ved en kollisjon eller en ugyldig publisering.
• En pause når fem kjøringer på rad feiler, vist på synkroniseringens side.
• Et varsel hver time når ingen kjøring har lyktes de siste 24 timene.
• Et samtykkefilter under kjøringen for kontakter som skrives til en markedsføringsmålgruppe, og en sjekk ved hver kjøring av at den er den publiserte versjonen.

Ikke bygget, og greit å vite før du stoler på det:

• En lesing som lykkes med null poster, rapporteres ikke som uleselig. Advarselen etter ti kjøringer dekker en del av det. Den dekker ikke Shopify-ordrer eller en kilde som returnerer for få poster.
• 24-timersvarselet når Tajo, ikke deg, og det gjør også advarselen etter ti kjøringer. Pausen vises derimot på synkroniseringens side.
• Timesjekken overvåker arbeidsområdet, ikke hver synkronisering. Én frisk synkronisering skjuler en stille ved siden av.
• Ikke noe kostnadstak per kjøring.
• Ingenting starter en pauset synkronisering på nytt. Det gjør en person.
• Pausen etter fem feil og 24-timerssjekken er satt for hele Tajo-installasjonen, ikke per synkronisering.

Når et av disse punktene dukker opp i din egen synkronisering, forteller Gjenopprett en synkronisering som har hengt seg opp eller feilet hva du ser og hva du skal gjøre.

Forfatterne skrev seks regler for et sammendrag en person leser hver morgen. En synkronisering har ingen leser om morgenen i det hele tatt, og derfor trenger den dem enda mer. Regel én til fire og regel seks er kode i runneren vår i dag. Regel fem er halvveis skrevet: En synkronisering som ikke kan lese kilden sin, burde si det.