Respostas
Se toda sessão tem que ler de um serviço antes de agir, o que acontece quando esse serviço tem um segundo ruim?
A leitura é tentada de novo em vez de falhar. Banco que escala a zero recusa a primeira chamada depois de um período ocioso enquanto o compute sobe, e ele diz isso: a recusa vem com uma marca explícita do fornecedor significando que a chamada não chegou a um compute e pode ser repetida. Essa marca era ignorada aqui, e a recusa viajava inteira até quem chamou como leitura falha — o que, para uma sessão cujo primeiro ato é conferir o que o time já decidiu, quer dizer seguir sem isso. Desde setembro de 2026 recusa com essa marca é repetida, em até três tentativas, custando da ordem de três quartos de segundo no pior caso. Dois limites impedem que isso vire licença: só a declaração do próprio fornecedor conta, nunca a nossa leitura de uma mensagem de erro, e só instrução que é inequivocamente leitura se repete. O que escreve é tentado exatamente uma vez, como antes.
Última atualização 22 de setembro de 2026
Conferência que pode falhar é conferência que as pessoas param de fazer
Ler antes de agir só sobrevive se ler for confiável. Na primeira vez em que a leitura de abertura dá erro no meio do trabalho, o trabalho segue sem ela, porque o trabalho é o que alguém está esperando. Na segunda, alguém a embrulha e segue. Na terceira ela é enfeite: ainda no código, ainda na descrição da rotina, e não sustenta mais nada. O custo de uma conferência não confiável nunca é a chamada que falhou — é a régua deixar de ser régua em silêncio, sem nada anunciar o dia em que isso aconteceu.
Quem diz que a chamada pode ser repetida é o fornecedor; a gente não adivinha
A decisão de repetir não é nossa para inferir. Banco que dorme quando fica ocioso responde a primeira chamada depois do silêncio com uma recusa que se declara repetível, porque a chamada não chegou a um compute de pé. É essa marca que se lê — nunca a prosa da mensagem, que é escrita para gente e é reescrita sem aviso. Recusa que não declara nada continua final: silêncio do fornecedor não é permissão. Essa direção importa mais do que parece, porque repetir o que o fornecedor não marcou é adivinhar que uma operação não surtiu efeito, e é esse tipo de palpite que um dia aplica alguma coisa duas vezes.
Leitura se repete; escrita é tentada uma vez
O segundo limite é a própria instrução, e o teste falha fechado: o que não é reconhecido com certeza como leitura pura não se repete. A assimetria é a razão inteira de isso ser seguro. Confundir leitura com escrita custa exatamente o comportamento antigo — a chamada não é repetida, e ninguém fica pior do que estava. Confundir escrita com leitura custa uma escrita aplicada duas vezes. Por isso o teste é deliberadamente estreito e deliberadamente desconfiado: instrução que abre como leitura mas carrega escrita em qualquer ponto dentro dela é tratada como escrita. E a retentativa tem teto — três tentativas, esperas curtas, algo como três quartos de segundo no pior caso — porque leitura que trava é pior que leitura que falha, já que nada do lado de quem chamou distingue uma da leitura que está funcionando.
Como isso aparece na prática
Uma rotina agendada abre às três da manhã. É a primeira coisa a tocar o projeto em várias horas, então o compute do banco está dormindo, e acordá-lo leva uma fração de segundo. A primeira instrução dela é a leitura de abertura: o que este time decidiu, o que está em curso, o que a noite anterior deixou. É essa chamada que encontra o compute subindo, e ela é recusada — com a marca do fornecedor dizendo que a chamada não chegou e pode ser repetida. No comportamento antigo, isso aparecia como erro. A rotina não parava, porque rotina que para com banco frio é rotina que para quase toda noite. Ela seguia e fazia o trabalho: abria arquivos, mudava coisas, escrevia o resultado. O que ela não fazia era ler as réguas, e nada na saída dela dizia isso. A parte cara não é a chamada que falhou — é a hora de trabalho construída em cima dela. Hoje a mesma recusa custa uma espera medida em centenas de milissegundos, a segunda tentativa encontra um compute de pé, e a leitura chega. A rotina nunca fica sabendo que algo aconteceu, e esse é o desfecho certo: compute acordando é infraestrutura, não notícia.
Perguntas que as pessoas fazem sobre isso
- Repetir não está só encobrindo uma indisponibilidade de verdade?
- Encobre exatamente as recusas que se declaram temporárias, e nada além disso. Indisponibilidade de verdade não produz essa declaração — produz conexão que não responde, ou erro sem marca nenhuma — e ali as tentativas acabam e a leitura falha à vista, dizendo quantas foram. A linha entre as duas é traçada pelo fornecedor na própria resposta, não pela gente lendo borra de café em texto de erro, e é isso que impede a retentativa de virar um jeito de não perceber.
- Quanto tempo quem chamou pode ficar esperando?
- Três tentativas, com esperas curtas entre elas, somando algo como três quartos de segundo no pior caso antes de a falha aparecer. O teto é pequeno de propósito. Esperar mais trocaria uma falha visível por uma invisível: quem chamou não distingue leitura lenta de leitura funcionando, e sessão travada enquanto confere as réguas é pior para todo mundo do que sessão avisada de que a conferência falhou.
- Preferimos que nosso agente falhe duro a agir com algo incompleto. Isso muda o que ele recebe?
- Não. A retentativa devolve a mesma leitura que a primeira tentativa devolveria; nada é descartado, resumido ou preenchido para a chamada dar certo. E a falha da qual você está se protegendo é justamente a que o comportamento antigo produzia: um agente que perguntou o que o time tinha decidido, ouviu que o banco estava ocupado, e seguiu assim mesmo. Se a leitura realmente não puder ser entregue, ela continua falhando — e falha alto o bastante para ser registrada em vez de absorvida.
Onde isto se confere
Documentação de produto neste site (Como funciona, Instalação), as respostas sobre leitura que deixa de custar o mesmo quando nada mudou e sobre rotinas de IA agendadas que perdem o fio, e as réguas de retentativa, classificação de leitura pura e segurança de escrita na especificação sancionada do produto. O comportamento descrito aqui chegou à produção em 12 de setembro de 2026. Tudo descrito aqui é comportamento que as ferramentas aplicam hoje, não roadmap.
https://www.arroway.app/pt-BR/answers/reads-that-recover-from-a-retryable-database-error