Seks regler for en synkronisering, der kører, mens ingen kigger

Den 8. oktober 2026 udgav Lance Martin og CJ Avilla en gennemgang af en agent, der hver morgen læser Slack og GitHub og poster et overblik i Slack. Ingen ser den køre. Deres mest nyttige afsnit handler om en fejl, der ligner succes. Når en kildes server er nede, eller dens token er udløbet, „ser agenten intet fra den kilde og melder ‚intet nyt‘“.

En kontaktsynkronisering fra Shopify til Brevo har samme fejl. Det samme gælder enhver planlagt synkronisering mellem to SaaS-værktøjer. En læsning, der fejler i stilhed, ligner præcis en butik, hvor ingen har tilmeldt sig i dag.

Deres artikel slutter med seks regler for en agent, der kører uden opsyn. Læs dem som en, der driver synkroniseringer, og hver af dem er en regel for reverse ETL. Workeren døde. Synkroniseringen gjorde ikke. følger én kontakt gennem et nedbrud. Denne side er tjeklisten ovenover: seks regler for en automatiseret datasynkronisering, hvad Tajos runner gør ved hver af dem i dag, og hvor den kommer til kort. Runnerens side er beskrevet i Genopret en synkronisering, der sidder fast eller er fejlet.

1. Læs fra et bogmærke, og flyt det først, når batchen er landet

Deres første regel: „Læs hver kilde fra et bogmærke, ikke fra et fast tidsvindue.“ Et vindue på „de seneste 24 timer“ efterlader et hul, når en kørsel starter sent, og gentager poster, når den starter tidligt.

En Tajo-synkronisering læser sin kilde i batches fra en gemt cursor. Cursoren flytter sig ved slutningen af en batch, og kun når hver post i den batch er landet. En kørsel, der fejler, beholder den sidste rene position, så den næste kørsel læser den afbrudte batch igen i stedet for at springe den over.

Ordrer får deres eget bogmærke. En planlagt synkronisering af Shopify-ordrer starter ved sin første planlagte kørsel og sender det, der er ændret siden den forrige. Tidligere ordrer sendes kun, når en person kører synkroniseringen. Planlagte kørsler og kørsler, som en person starter, har hver deres cursor, så en indlæsning af historik eller en testbatch ikke kan spole den planlagte tilbage.

Prisen er, at en afbrudt batch læses to gange. Regel 2 gør det sikkert.

2. Giv hver skrivning en nøgle, der overlever nedbruddet

Deres fjerde regel tæller først en besked som sendt, „når Slack bekræfter den“, og opdaterer først da bogmærket og ledgeren. Et anbefalet brev fungerer sådan. Det er leveret, når den underskrevne kvittering kommer tilbage, ikke når det forlader skranken.

Før Tajo skriver en post, får posten en leveringsnøgle. Nøglen er et hash af synkroniseringen, kilden, sidecursoren, positionen på siden og selve posten, så den indeholder ingen persondata. Den reserveres, før destinationen kaldes, og markeres som gennemført, når skrivningen lykkes. Gennemførte nøgler gemmes i syv dage. Et genforsøg eller en senere planlagt kørsel udleder den samme nøgle for den samme post, finder den gennemført og kalder ikke destinationen igen.

Det har to omkostninger. Efter syv dage glemmer ledgeren, og en genafspilning fra en ældre cursor kan skrive igen. Og en skrivning, der får timeout, efterlader en ærlig tvivl: Det andet system har måske gemt den uden at svare. Tajo prøver den skrivning igen ved et senere forsøg i stedet for at registrere den som fejlet i syv dage. En connector, der giver destinationen sin egen idempotensnøgle, fjerner den tvivl. En, der ikke kan, står tilbage med risikoen for én dublet.

3. Én kørsel ejer synkroniseringen og beviser det før hver skrivning

Deres tredje regel: „Tjek hvert element igen lige før du poster.“ For en synkronisering er det, der oftest har ændret sig mellem læsning og skrivning, hvem der må skrive.

Hver Tajo-synkronisering har én lease med sit eget token og en levetid på 15 minutter, der fornyes hvert femte minut. En kørsel tjekker, at den stadig har leasen, før den kalder destinationen, og igen før den flytter cursoren. En kørsel, der har mistet den, stopper, og dens side siger „Kørslen mistede sin plads undervejs og stoppede for ikke at skrive to gange.“ En anden kørsel, der støder ind i en igangværende, slutter i stedet for at stille sig i kø bagved.

Posterne tjekkes også. Mellem læsning og skrivning går posterne gennem samtykkefilteret. En kontakt, der ville blive skrevet til en marketingmålgruppe uden dokumenterbart samtykke, afvises i stedet for at blive gættet. Med hjælpesidens ord er fejltilstanden „for forsigtig“, aldrig „sendt for meget“.

4. Prøv igen ved det forbigående, stop ved det vedvarende

Deres seks regler siger intet om, hvor tit man skal prøve igen. En synkronisering har brug for den regel, fordi dens mest almindelige fejl er en rate limit og et dårligt minut hos en leverandør.

En Tajo-kørsel fra køen, der fejler, får fem forsøg. Ventetiderne imellem er 60, 120, 240 og 480 sekunder, cirka et kvarter i alt. Nogle fejl prøves aldrig igen, fordi et nyt forsøg ikke kan løse dem. En kørsel, der stødte ind i en allerede igangværende kørsel, prøves ikke igen, og det gør en kørsel heller ikke, hvis dens publicerede version eller forbindelser ikke længere er gyldige.

En stime er noget andet end et uheld. Hvis de seneste fem afsluttede kørsler, siden synkroniseringen sidst blev ændret, alle fejlede, sætter Tajo synkroniseringen på pause og viser den seneste fejl på dens side. Én succes nulstiller tællingen. Intet genstarter en pauset synkronisering af sig selv; en person retter årsagen og publicerer den igen. Artiklen om den døde worker fortæller om den hændelse, der skabte denne regel.

5. Behandl stilhed som et fund

„Rapportér en fejlet læsning som ulæselig, aldrig som en stille dag.“ Det er den sværeste af de seks, og den, vi kun delvist lever op til.

Hvor den holder: En læsning, der giver en fejl, får kørslen til at fejle. Et afvist token eller en server, der ikke svarer, sender intet til destinationen, lader cursoren blive, hvor den var, og tæller med i pausen efter fem fejlede kørsler. Og hver time, 13 minutter over, tjekker Tajo hvert workspace med en aktiv synkronisering. Den alarmerer sit eget team, når der ikke har været en vellykket kørsel i de seneste 24 timer, også for et workspace, hvor der slet ikke er registreret nogen kørsel. Det er det timelige tjek.

Hvor den ikke holder: Den stille læsning, forfatterne beskriver, er en læsning, der svarer „OK“ uden poster. Vores runner tæller det som en succes. For kilder som Shopify-kunder advarer et separat tjek Tajos team efter ti vellykkede kørsler i træk med nul poster, hvis synkroniseringen har leveret poster før. Shopify-ordrer læses efter opdateringstidspunkt, så en tom kørsel er normal dér, og det tjek kører ikke. En kilde, der returnerer nogle poster, men færre end den burde, bliver slet ikke opdaget.

Indvendingen lyder sådan: „Ti tomme kørsler er to en halv time med en plan på 15 minutter. Hvorfor ikke slå alarm ved den første?“ Kontaktsynkroniseringer kører som standard hvert 15. minut. Og en butik uden nye kunder i et kvarter er helt almindelig. En alarm ved den første tomme kørsel ville gå i gang hver nat, og en alarm, der altid går i gang, er en, ingen læser. Den grænse bytter hastighed for troværdighed. Den er stadig et gæt om stilhed, ikke forfatternes regel.

6. Bestem én gang, hvad synkroniseringen må skrive, og lad hver kørsel bevise det

Deres femte regel henter agentens præferencer „fra et lager, agenten ikke kan redigere“. Deres sjette giver agenten skrivebeskyttet adgang alle steder, hvor den kun læser, og sætter loft over, hvad hver kørsel må bruge. Begge findes, fordi agenten læser tekst, andre har skrevet, og den tekst kan forsøge at give den ordrer.

Synkroniseringens udgave af præferencefilen er den publicerede regel. At publicere en Tajo-synkronisering binder den til et digest af præcis den regel, der blev vist i forhåndsvisningen. Redigering sender den tilbage til kladde, og den går gennem forhåndsvisningen igen, før den kører igen. Hver kørsel tjekker, før den ændrer noget, at den kører netop den publicerede version med de forbindelser, den blev publiceret med. En kørsel, der ikke består det tjek, prøves ikke igen. Retningen ligger også fast: En synkroniseringsregel skriver én vej og aldrig tilbage i Shopify.

Udgiftsloftet har ikke noget modstykke. Vores synkroniseringskørsler har ingen udgiftsgrænse pr. kørsel. Grænsen for genforsøg og pausen begrænser, hvor længe en fejl kan stå på, ikke hvad en kørsel koster.

Hvad der er bygget, og hvad der ikke er

Bygget, da dette blev skrevet:

• En cursor, der først flytter sig efter en batch, hvor hver post er landet, og en planlagt ordrecursor, som kørsler startet af en person ikke kan spole tilbage.
• En leveringsnøgle pr. post, tjekket mod en ledger over gennemførte skrivninger, der gemmes i syv dage.
• Én lease pr. synkronisering, tjekket før skrivningen og før cursoren flytter sig.
• Fem forsøg pr. kørsel med 60 sekunders ventetid og derefter 120, 240 og 480, uden genforsøg ved en kollision eller en ugyldig publicering.
• En pause, når fem kørsler i træk fejler, vist på synkroniseringens side.
• En timelig alarm, når ingen kørsel er lykkedes i de seneste 24 timer.
• Et samtykkefilter under kørslen for kontakter, der skrives til en marketingmålgruppe, og et tjek ved hver kørsel af, at den er den publicerede version.

Ikke bygget, og godt at vide, før du stoler på det:

• En læsning, der lykkes med nul poster, rapporteres ikke som ulæselig. Advarslen efter ti kørsler dækker en del af det. Den dækker ikke Shopify-ordrer eller en kilde, der returnerer for få poster.
• 24-timers-alarmen når Tajo, ikke dig, og det samme gør advarslen efter ti kørsler. Pausen vises dog på synkroniseringens side.
• Det timelige tjek overvåger workspacet, ikke hver synkronisering. Én sund synkronisering skjuler en tavs ved siden af.
• Intet udgiftsloft pr. kørsel.
• Intet genstarter en pauset synkronisering. Det gør en person.
• Pausen efter fem fejl og 24-timers-tjekket er sat for hele Tajo-installationen, ikke pr. synkronisering.

Når et af disse punkter dukker op på din egen synkronisering, fortæller Genopret en synkronisering, der sidder fast eller er fejlet, hvad du ser, og hvad du skal gøre.

Forfatterne skrev seks regler for et overblik, som en person læser hver morgen. En synkronisering har slet ingen læser om morgenen, og derfor har den endnu mere brug for dem. Regel et til fire og regel seks er kode i vores runner i dag. Regel fem er halvt skrevet: En synkronisering, der ikke kan læse sin kilde, burde sige det.