Seis regras para uma sincronização que roda enquanto ninguém olha

Em 8 de outubro de 2026, Lance Martin e CJ Avilla publicaram um passo a passo de um agente que lê o Slack e o GitHub toda manhã e publica um resumo no Slack. Ninguém o observa enquanto ele roda. O parágrafo mais útil deles trata de uma falha que parece sucesso. Quando o servidor de uma origem está fora do ar ou o token dela expirou, “o agente não vê nada dessa origem e informa ‘nada de novo’”.

Uma sincronização de contatos do Shopify para o Brevo tem a mesma falha. Assim como toda sincronização agendada entre duas ferramentas SaaS. Uma leitura que falha em silêncio parece exatamente uma loja em que ninguém se cadastrou hoje.

O artigo deles termina com seis regras para um agente que roda sem supervisão. Leia-as como quem opera sincronizações e cada uma vira uma regra de reverse ETL. O worker morreu. A sincronização, não. acompanha um contato durante uma queda. Esta página é a checklist acima dele: seis regras para uma sincronização de dados automatizada, o que o runner da Tajo faz hoje em cada uma e onde ele fica devendo. O lado do runner está descrito em Recuperar uma sincronização travada ou com falha.

1. Leia a partir de um marcador e mova-o só quando o lote tiver chegado

A primeira regra deles: “Leia cada origem a partir de um marcador, não de uma janela de tempo fixa.” Uma janela de “últimas 24 horas” deixa uma lacuna quando uma execução começa atrasada e repete registros quando começa adiantada.

Uma sincronização da Tajo lê sua origem em lotes a partir de um cursor salvo. O cursor avança no fim de um lote, e só quando todos os registros desse lote chegaram. Uma execução que falha mantém a última posição limpa, então a execução seguinte lê de novo o lote interrompido em vez de pulá-lo.

Os pedidos ganham um marcador próprio. Uma sincronização agendada de pedidos do Shopify começa na primeira execução agendada e envia o que mudou desde a anterior. Pedidos antigos só vão quando uma pessoa executa a sincronização. Execuções agendadas e execuções iniciadas por uma pessoa têm cursores separados, então uma carga do histórico ou um lote de teste não consegue fazer o agendado voltar atrás.

O custo é que um lote interrompido é lido duas vezes. A regra 2 é o que torna isso seguro.

2. Dê a cada gravação uma chave que sobreviva à queda

A quarta regra deles só conta uma mensagem como enviada “quando o Slack confirma”, e só então atualiza o marcador e o registro. Uma carta registrada funciona assim. Ela está entregue quando o aviso de recebimento assinado volta, não quando sai do balcão.

Antes de a Tajo gravar um registro, o registro recebe uma chave de entrega. A chave é um hash da sincronização, da origem, do cursor da página, da posição na página e do próprio registro, então não contém dados pessoais. Ela é reservada antes de o destino ser chamado e marcada como concluída quando a gravação dá certo. As chaves concluídas são mantidas por sete dias. Uma nova tentativa, ou uma execução agendada posterior, calcula a mesma chave para o mesmo registro, encontra-a concluída e não chama o destino de novo.

Isso tem dois custos. Depois de sete dias, o registro esquece, e uma repetição a partir de um cursor mais antigo pode gravar de novo. E uma gravação que estoura o tempo deixa uma dúvida honesta: o outro sistema pode tê-la salvado sem responder. A Tajo tenta essa gravação de novo em uma tentativa posterior, em vez de registrá-la como falha por sete dias. Um conector que entrega ao destino uma chave de idempotência própria elimina essa dúvida. Um que não consegue fica com a chance de um duplicado.

3. Uma execução é dona da sincronização e prova isso antes de cada gravação

A terceira regra deles: “Verifique cada item de novo logo antes de publicar.” Em uma sincronização, o que mais provavelmente mudou entre a leitura e a gravação é quem tem permissão para gravar.

Cada sincronização da Tajo tem um lease, com token próprio e vida de 15 minutos, renovada a cada cinco minutos. Uma execução confere que ainda detém o lease antes de chamar o destino, e de novo antes de mover o cursor. Uma execução que o perdeu para, e a página dela mostra “A execução perdeu sua vaga no meio do caminho e parou para evitar escrever duas vezes.” Uma segunda execução que colide com outra em andamento termina em vez de entrar na fila atrás dela.

Os registros também são verificados. Entre a leitura e a gravação, os registros passam pelo filtro de consentimento. Um contato gravado em um público de marketing sem consentimento comprovável é recusado em vez de presumido. Nas palavras da página de ajuda, o modo de falha é “cuidadoso demais”, nunca “enviado demais”.

4. Tente de novo o que é passageiro, pare o que não é

As seis regras deles não dizem nada sobre quantas vezes tentar de novo. Uma sincronização precisa dessa regra, porque suas falhas mais comuns são um limite de taxa e um minuto ruim de um fornecedor.

Uma execução da Tajo em fila que falha recebe cinco tentativas. As esperas entre elas são de 60, 120, 240 e 480 segundos, cerca de quinze minutos no total. Algumas falhas nunca são repetidas, porque tentar de novo não as resolve. Uma execução que colidiu com outra já em andamento não é repetida, nem uma execução cuja versão publicada ou cujas conexões não são mais válidas.

Uma sequência é diferente de um tropeço. Se as últimas cinco execuções concluídas desde a última alteração da sincronização falharam todas, a Tajo pausa a sincronização e mostra o último erro na página dela. Um único sucesso zera a contagem. Nada reinicia sozinho uma sincronização pausada; uma pessoa corrige a causa e a publica de novo. O artigo do worker que morreu conta o incidente que deu origem a essa regra.

5. Trate o silêncio como um achado

“Informe uma leitura com falha como ilegível, nunca como um dia tranquilo.” É a mais difícil das seis, e a que cumprimos só em parte.

Onde ela vale: uma leitura com erro faz a execução falhar. Um token recusado ou um servidor que não responde não envia nada ao destino, deixa o cursor onde estava e conta para a pausa depois de cinco execuções com falha. E a cada hora, aos 13 minutos, a Tajo verifica todo workspace com uma sincronização ativa. Ela alerta a própria equipe quando não houve nenhuma execução bem-sucedida nas últimas 24 horas, inclusive em um workspace onde nenhuma execução foi registrada. Essa é a verificação de hora em hora.

Onde ela não vale: a leitura silenciosa que os autores descrevem é uma leitura que responde “OK” sem registros. Nosso runner conta isso como sucesso. Para origens como os clientes do Shopify, uma verificação separada avisa a equipe da Tajo depois de dez execuções bem-sucedidas seguidas com zero registros, se a sincronização já tinha produzido registros antes. Os pedidos do Shopify são lidos pela data de atualização, então uma execução vazia é normal ali e essa verificação não roda. Uma origem que devolve alguns registros, mas menos do que deveria, não é detectada de forma alguma.

A objeção é esta: “Dez execuções vazias são duas horas e meia em um agendamento de 15 minutos. Por que não alertar na primeira?” As sincronizações de contatos rodam a cada 15 minutos por padrão. E uma loja sem clientes novos em quinze minutos é algo comum. Um alerta na primeira execução vazia dispararia toda noite, e um alerta que sempre dispara é um alerta que ninguém lê. Esse limite troca velocidade por credibilidade. Continua sendo um palpite sobre o silêncio, não a regra dos autores.

6. Decida uma vez o que a sincronização pode gravar e faça cada execução provar isso

A quinta regra deles guarda as preferências do agente “em um armazenamento que o agente não pode editar”. A sexta dá ao agente acesso somente leitura onde ele só lê e limita quanto cada execução pode gastar. As duas existem porque o agente lê textos que outras pessoas escreveram, e esses textos podem tentar dar ordens a ele.

A versão do arquivo de preferências em uma sincronização é a regra publicada. Publicar uma sincronização da Tajo a vincula a um digest da regra exata que foi pré-visualizada. Editá-la a devolve para rascunho, e ela passa de novo pela pré-visualização antes de rodar outra vez. Cada execução verifica, antes de mudar qualquer coisa, que está rodando essa versão publicada com as conexões com que foi publicada. Uma execução que falha nessa verificação não é repetida. A direção também é fixa: uma regra de sincronização grava em um só sentido e nunca de volta no Shopify.

O limite de gasto não tem equivalente. Nossas execuções de sincronização não têm limite de gasto por execução. O limite de tentativas e a pausa restringem quanto tempo uma falha pode durar, não quanto uma execução custa.

O que está construído e o que não está

Construído, no momento em que escrevemos:

• Um cursor que só avança depois de um lote em que todos os registros chegaram, e um cursor agendado de pedidos que execuções iniciadas por uma pessoa não conseguem fazer voltar.
• Uma chave de entrega por registro, conferida em um registro de gravações concluídas mantido por sete dias.
• Um lease por sincronização, verificado antes da gravação e antes de o cursor avançar.
• Cinco tentativas por execução, com espera de 60 segundos e depois de 120, 240 e 480, sem nova tentativa em caso de colisão ou publicação inválida.
• Uma pausa depois de cinco execuções seguidas com falha, mostrada na página da sincronização.
• Um alerta de hora em hora quando nenhuma execução deu certo nas últimas 24 horas.
• Um filtro de consentimento no momento da execução para contatos gravados em um público de marketing, e uma verificação em cada execução de que ela é a versão publicada.

Não construído, e bom saber antes de confiar nisso:

• Uma leitura que dá certo com zero registros não é informada como ilegível. O aviso depois de dez execuções cobre parte disso. Ele não cobre os pedidos do Shopify nem uma origem que devolve registros de menos.
• O alerta de 24 horas chega à Tajo, não a você, e o aviso depois de dez execuções também. A pausa aparece, sim, na página da sincronização.
• A verificação de hora em hora observa o workspace, não cada sincronização. Uma sincronização saudável esconde uma silenciosa ao lado dela.
• Nenhum limite de gasto por execução.
• Nada reinicia uma sincronização pausada. Uma pessoa faz isso.
• A pausa depois de cinco falhas e a verificação de 24 horas são definidas para toda a implantação da Tajo, não por sincronização.

Quando um desses casos aparecer na sua sincronização, Recuperar uma sincronização travada ou com falha diz o que você vê e o que fazer.

Os autores escreveram seis regras para um resumo que uma pessoa lê toda manhã. Uma sincronização não tem leitor nenhum de manhã, e é por isso que precisa delas ainda mais. As regras de um a quatro e a regra seis são código no nosso runner hoje. A regra cinco está escrita pela metade: uma sincronização que não consegue ler sua origem deveria dizer isso.