Sei regole per una sincronizzazione che gira mentre nessuno guarda

L’8 ottobre 2026 Lance Martin e CJ Avilla hanno pubblicato la descrizione di un agente che ogni mattina legge Slack e GitHub e pubblica un riepilogo su Slack. Nessuno lo guarda mentre gira. Il loro paragrafo più utile parla di un errore che sembra un successo. Quando il server di una sorgente è giù o il suo token è scaduto, «l’agente non vede nulla da quella sorgente e riporta “niente di nuovo”».

Una sincronizzazione dei contatti da Shopify a Brevo ha lo stesso errore. Come ogni sincronizzazione programmata tra due strumenti SaaS. Una lettura che fallisce in silenzio sembra esattamente un negozio in cui oggi non si è iscritto nessuno.

Il loro articolo si chiude con sei regole per un agente che gira senza sorveglianza. Leggile da persona che gestisce sincronizzazioni e ognuna diventa una regola di reverse ETL. Il worker è morto. La sincronizzazione no. segue un contatto attraverso un crash. Questa pagina è la checklist che sta sopra: sei regole per una sincronizzazione automatica dei dati, cosa fa oggi il runner di Tajo per ciascuna e dove non basta. La parte del runner è descritta in Ripristinare una sincronizzazione bloccata o fallita.

1. Leggi da un segnalibro, e spostalo solo quando il batch è arrivato

La loro prima regola: «Leggi ogni sorgente da un segnalibro, non da una finestra di tempo fissa». Una finestra delle «ultime 24 ore» lascia un buco quando un’esecuzione parte in ritardo e ripete i record quando parte in anticipo.

Una sincronizzazione Tajo legge la sua sorgente a batch da un cursore salvato. Il cursore avanza alla fine di un batch, e solo quando ogni record di quel batch è arrivato. Un’esecuzione che fallisce mantiene l’ultima posizione pulita, così l’esecuzione successiva rilegge il batch interrotto invece di saltarlo.

Gli ordini hanno un segnalibro tutto loro. Una sincronizzazione programmata degli ordini Shopify parte dalla sua prima esecuzione programmata e invia ciò che è cambiato dalla precedente. Gli ordini passati partono solo quando una persona esegue la sincronizzazione. Le esecuzioni programmate e quelle avviate da una persona hanno cursori separati, così un recupero dello storico o un batch di prova non possono riportare indietro quello programmato.

Il prezzo è che un batch interrotto viene letto due volte. La regola 2 è ciò che lo rende sicuro.

2. Dai a ogni scrittura una chiave che sopravvive al crash

La loro quarta regola conta un messaggio come inviato «solo quando Slack lo conferma», e solo allora aggiorna il segnalibro e il registro. Una raccomandata funziona così. È consegnata quando torna la ricevuta firmata, non quando lascia lo sportello.

Prima che Tajo scriva un record, il record riceve una chiave di consegna. La chiave è un hash della sincronizzazione, della sorgente, del cursore di pagina, della posizione nella pagina e del record stesso, quindi non contiene dati personali. Viene riservata prima di chiamare la destinazione e segnata come completata quando la scrittura riesce. Le chiavi completate sono conservate sette giorni. Un nuovo tentativo, o un’esecuzione programmata successiva, ricalcola la stessa chiave per lo stesso record, la trova completata e non chiama di nuovo la destinazione.

Ha due costi. Dopo sette giorni il registro dimentica, e una ripetizione da un cursore più vecchio può scrivere di nuovo. E una scrittura che va in timeout lascia un dubbio legittimo: l’altro sistema potrebbe averla salvata senza rispondere. Tajo ritenta quella scrittura in un tentativo successivo invece di registrarla come fallita per sette giorni. Un connettore che passa alla destinazione una propria chiave di idempotenza chiude quel dubbio. Uno che non può resta con la possibilità di un duplicato.

3. Una sola esecuzione possiede la sincronizzazione, e lo dimostra prima di ogni scrittura

La loro terza regola: «Ricontrolla ogni elemento subito prima di pubblicarlo». Per una sincronizzazione, la cosa che più probabilmente è cambiata tra la lettura e la scrittura è chi ha il permesso di scrivere.

Ogni sincronizzazione Tajo ha un lease, con un proprio token e una durata di 15 minuti rinnovata ogni cinque minuti. Un’esecuzione verifica di detenere ancora il lease prima di chiamare la destinazione, e di nuovo prima di spostare il cursore. Un’esecuzione che l’ha perso si ferma, e la sua pagina dice «L’esecuzione ha perso il suo slot a metà ed è stata fermata per evitare di scrivere due volte». Una seconda esecuzione che si scontra con una in corso termina invece di mettersi in coda dietro.

Anche i record vengono controllati. Tra la lettura e la scrittura, i record passano per il filtro del consenso. Un contatto scritto in un pubblico di marketing senza consenso dimostrabile viene rifiutato invece che indovinato. Con le parole della pagina di aiuto, la modalità di errore è «troppo prudente», mai «troppi invii».

4. Ritenta ciò che passa, ferma ciò che non passa

Le loro sei regole non dicono nulla su quante volte riprovare. Una sincronizzazione ha bisogno di questa regola, perché i suoi errori più comuni sono un limite di frequenza e un brutto minuto di un fornitore.

Un’esecuzione Tajo in coda che fallisce riceve cinque tentativi. Le attese tra un tentativo e l’altro sono di 60, 120, 240 e 480 secondi, circa quindici minuti in tutto. Alcuni errori non vengono mai ritentati, perché riprovare non può risolverli. Un’esecuzione che si è scontrata con una già in corso non viene ritentata, e nemmeno un’esecuzione la cui versione pubblicata o le cui connessioni non sono più valide.

Una serie è diversa da un inciampo. Se le ultime cinque esecuzioni concluse dall’ultima modifica della sincronizzazione sono tutte fallite, Tajo mette in pausa la sincronizzazione e mostra l’ultimo errore sulla sua pagina. Un solo successo azzera il conteggio. Niente riavvia da solo una sincronizzazione in pausa; una persona corregge la causa e la pubblica di nuovo. L’articolo sul worker morto racconta l’incidente da cui è nata questa regola.

5. Tratta il silenzio come un risultato

«Segnala una lettura fallita come illeggibile, mai come una giornata tranquilla». È la più difficile delle sei, e quella che rispettiamo solo in parte.

Dove regge: una lettura che va in errore fa fallire l’esecuzione. Un token rifiutato o un server che non risponde non invia nulla alla destinazione, lascia il cursore dov’era e conta per la pausa dopo cinque esecuzioni fallite. E ogni ora, al tredicesimo minuto, Tajo controlla ogni workspace con una sincronizzazione attiva. Avvisa il proprio team quando nelle ultime 24 ore non c’è stata nessuna esecuzione riuscita, anche per un workspace in cui non è stata registrata alcuna esecuzione. È il controllo orario.

Dove non regge: la lettura silenziosa descritta dagli autori è una lettura che risponde «OK» senza record. Il nostro runner la conta come un successo. Per sorgenti come i clienti Shopify, un controllo separato avvisa il team di Tajo dopo dieci esecuzioni riuscite di fila con zero record, se la sincronizzazione aveva prodotto record in precedenza. Gli ordini Shopify sono letti per data di aggiornamento, quindi lì un’esecuzione vuota è normale e quel controllo non viene eseguito. Una sorgente che restituisce alcuni record, ma meno di quanti dovrebbe, non viene rilevata affatto.

L’obiezione suona così: «Dieci esecuzioni vuote sono due ore e mezza con una cadenza di 15 minuti. Perché non avvisare alla prima?». Le sincronizzazioni dei contatti girano davvero ogni 15 minuti per impostazione predefinita. E un negozio senza nuovi clienti per un quarto d’ora è normale. Un avviso alla prima esecuzione vuota scatterebbe ogni notte, e un avviso che scatta sempre è un avviso che nessuno legge. Quella soglia scambia velocità con credibilità. Resta un’ipotesi sul silenzio, non la regola degli autori.

6. Decidi una volta cosa può scrivere la sincronizzazione, e fai dimostrare ogni esecuzione

La loro quinta regola tiene le preferenze dell’agente «in un archivio che l’agente non può modificare». La sesta dà all’agente accesso in sola lettura ovunque si limiti a leggere, e mette un tetto a quanto può spendere ogni esecuzione. Entrambe esistono perché l’agente legge testo scritto da altri, e quel testo può provare a dargli ordini.

La versione per la sincronizzazione del file delle preferenze è la regola pubblicata. Pubblicare una sincronizzazione Tajo la lega a un digest della regola esatta che è stata vista in anteprima. Modificarla la riporta in bozza, e ripassa per l’anteprima prima di girare di nuovo. Ogni esecuzione verifica, prima di cambiare qualsiasi cosa, di stare eseguendo quella versione pubblicata con le connessioni con cui è stata pubblicata. Un’esecuzione che non supera quel controllo non viene ritentata. Anche la direzione è fissa: una regola di sincronizzazione scrive in un solo senso e mai di ritorno in Shopify.

Il tetto di spesa non ha un equivalente. Le nostre esecuzioni di sincronizzazione non hanno un limite di spesa per esecuzione. Il limite dei tentativi e la pausa limitano quanto può durare un errore, non quanto costa un’esecuzione.

Cosa è costruito, e cosa no

Costruito, al momento in cui scriviamo:

• Un cursore che avanza solo dopo un batch in cui ogni record è arrivato, e un cursore programmato degli ordini che le esecuzioni avviate da una persona non possono riportare indietro.
• Una chiave di consegna per record, verificata in un registro delle scritture completate conservato sette giorni.
• Un lease per sincronizzazione, verificato prima della scrittura e prima che il cursore avanzi.
• Cinque tentativi per esecuzione, con un’attesa di 60 secondi e poi di 120, 240 e 480, senza nuovo tentativo per una collisione o una pubblicazione non valida.
• Una pausa dopo cinque esecuzioni fallite di fila, mostrata sulla pagina della sincronizzazione.
• Un avviso orario quando nessuna esecuzione è riuscita nelle ultime 24 ore.
• Un filtro del consenso al momento dell’esecuzione per i contatti scritti in un pubblico di marketing, e un controllo a ogni esecuzione che sia la versione pubblicata.

Non costruito, e utile da sapere prima di farci affidamento:

• Una lettura che riesce con zero record non viene segnalata come illeggibile. L’avviso dopo dieci esecuzioni ne copre una parte. Non copre gli ordini Shopify né una sorgente che restituisce troppo pochi record.
• L’avviso delle 24 ore arriva a Tajo, non a te, e lo stesso vale per l’avviso dopo dieci esecuzioni. La pausa invece compare sulla pagina della sincronizzazione.
• Il controllo orario sorveglia il workspace, non ogni sincronizzazione. Una sincronizzazione sana ne nasconde una silenziosa accanto.
• Nessun tetto di spesa per esecuzione.
• Niente riavvia una sincronizzazione in pausa. Lo fa una persona.
• La pausa dopo cinque errori e il controllo delle 24 ore sono impostati per l’intera installazione di Tajo, non per sincronizzazione.

Quando uno di questi casi compare sulla tua sincronizzazione, Ripristinare una sincronizzazione bloccata o fallita spiega cosa vedi e cosa fare.

Gli autori hanno scritto sei regole per un riepilogo che una persona legge ogni mattina. Una sincronizzazione non ha nessun lettore al mattino, ed è per questo che ne ha ancora più bisogno. Le regole dalla uno alla quattro e la regola sei sono codice nel nostro runner oggi. La regola cinque è scritta a metà: una sincronizzazione che non riesce a leggere la sua sorgente dovrebbe dirlo.