Existe uma classe de fonte pública que não devolve o documento na hora. Você pede a certidão, ela aceita o pedido, devolve um número de protocolo e informa que o arquivo sai depois. "Depois" pode ser cinco minutos ou três dias.
Parece detalhe operacional. Não é. Essa diferença muda quando a consulta é cobrada, o que a tela pode prometer, quando o processo pode seguir sem esperar e o que o relatório entregue ao cliente tem direito de afirmar.
Quase toda automação de coleta é desenhada supondo que a fonte responde. Este artigo é sobre a classe que não responde, e sobre as decisões que ela obriga a tomar.
O desenho padrão quebra em três lugares
O carregando promete uma coisa que ninguém sabe
A reação intuitiva é mostrar um indicador de carregamento e esperar. O problema é que ninguém sabe quando o arquivo vem: quem sabe é o órgão, e ele não avisa. O indicador comunica "já vai" para uma espera de duração desconhecida.
Se a fonte demora mais que o previsto, a pessoa esperou olhando uma informação falsa. Numa fonte de três dias, a promessa é absurda: ninguém fica com a aba aberta por três dias.
O prazo fixo mata o documento antes de ele nascer
A segunda armadilha é ter um único prazo de expiração para tudo. Se o sistema declara qualquer documento pendente como vencido depois de quinze minutos, o documento de uma fonte de três dias nasce morto. Ele expira na segunda-feira e o arquivo chega na quarta, para um sistema que já desistiu.
O prazo precisa ser propriedade do documento, não do sistema. Cinco minutos, quinze minutos e três dias têm que ser exatamente o mesmo fluxo, mudando um número declarado por fonte.
A peça que falta congela o processo inteiro
A terceira é a mais cara e a menos percebida. Se qualquer pendência bloqueia o processo, então uma certidão que sai em três dias trava o relatório, a análise e a decisão por três dias.
E isso já morde em fonte rápida: quinze minutos de bloqueio numa operação que roda o dia inteiro é tempo real perdido, todo dia, sem ninguém contabilizar.
Primeira decisão: quando se cobra
A resposta que sustenta o resto é: cobra-se no protocolo, não na entrega.
A fonte já executou quando aceitou o pedido. Ela consumiu o acesso, registrou a solicitação no órgão e, em muitos casos, já faturou. O arquivo que sai depois é a conclusão de um trabalho que já aconteceu, não um trabalho novo.
Daí decorre a regra simétrica, e ela é a parte que costuma faltar: o download nunca é cobrado. Baixar o documento três dias depois, ou baixar de novo três meses depois, não gera cobrança nova. Quem cobra por download está cobrando duas vezes pela mesma execução.
Isso tem uma consequência desconfortável e é melhor enunciá-la: o cliente paga por uma consulta cujo resultado ainda não existe. Esconder isso do extrato é o que transforma dúvida em chamado. O caminho honesto é marcar a linha, mostrar o protocolo ao lado do valor e deixar o cliente conferir na fonte sem precisar perguntar nada.
Segunda decisão: o resultado que ainda não existe
Aqui está a parte que quase todo mundo modela errado.
Numa fonte assíncrona, o "nada consta" só é conhecido quando o documento sai. Antes disso não existe resultado nenhum: existe um pedido aceito. São coisas diferentes, e tratá-las como iguais produz uma afirmação falsa.
O erro clássico é pintar essa linha como falha. A fonte respondeu, aceitou e devolveu protocolo, mas o painel mostra vermelho ou amarelo de erro, e o texto automático escreve "não foi possível consultar". Isso vai para o relatório, vai para o CRM, e dias depois o resultado chega e contradiz o que já foi dito.
O tratamento correto tem três partes:
- A linha tem estado próprio, que não é sucesso nem falha, e não oferece "tentar de novo", porque não há o que refazer.
- O protocolo aparece, na tela e no relatório. É o que permite ao cliente conferir na fonte.
- O relatório declara a pendência. Um documento que parece completo e não é, entregue a uma área de compliance, é pior que um relatório que assume a lacuna.
E vale para o texto gerado por IA também. Se o modelo lê a análise e não recebe explicitamente "esta consulta tem pedido protocolado", ele conta os documentos, não encontra aquele e escreve que a fonte não respondeu. Trocamos um indicador que mente por um texto que afirma o que não sabe, e o texto vai mais longe.
Terceira decisão: falha nunca vira resposta
Esta é a regra que separa automação madura de script.
Quando o portal cai, quando a sessão expira no meio, quando a verificação anti-robô falha ou quando o layout muda e o campo some, existe uma tentação enorme de gravar o resultado vazio. A tela vazia vira "nada consta" e o registro entra no sistema com cara de resposta legítima.
A regra tem que ser absoluta: resposta que não é claramente um resultado volta para a fila de reprocessamento. É preferível demorar mais a responder do que responder errado com confiança.
O mesmo vale para a mudança de layout. Se a extração para de encontrar o campo, isso precisa gerar falha alta e visível, nunca campo em branco. Campo em branco por mudança de layout é indistinguível de campo legitimamente vazio.
De quanto em quanto tempo perguntar
Definido que o processo segue sem esperar, sobra a pergunta operacional: com que frequência o robô volta à fonte para ver se o documento saiu.
O erro é começar do zero
A resposta reflexa é um intervalo que cresce: pergunta em um minuto, depois em dois, depois em quatro. Funciona bem numa fonte de cinco minutos.
Numa fonte de dois dias, essa mesma lógica começa a perguntar no primeiro minuto de um processo que leva quarenta e oito horas. Toda pergunta feita na primeira metade do prazo tem resposta conhecida de antemão: ainda não. É desperdício puro, e é o único tipo de desperdício que se elimina sem pagar nada em troca.
Ancorar no prazo esperado
A política que funciona tem três fases:
- Silêncio, até algo em torno de sessenta por cento do prazo esperado. Zero chamadas.
- Janela quente, com intervalos curtos crescendo devagar, que é onde o documento de fato aparece.
- Cauda, com um teto de intervalo até o limite de desistência.
O efeito numa fonte de três dias, medido:
| política | chamadas por documento |
|---|---|
| escada curta repetindo o último degrau | cerca de 1.400 |
| intervalo crescente começando do zero | cerca de 77 |
| ancorada no prazo esperado | cerca de 10 |
Duas observações honestas sobre essa tabela. A primeira: o ganho grande vem de não perguntar cedo, não de perguntar devagar. A segunda: o preço da economia é atraso na descoberta, limitado pelo teto do intervalo. Quem escolhe o teto está escolhendo entre chamadas e demora, e a escolha muda se cada chamada tiver custo financeiro em vez de custo de rede.
Nada disso é conexão aberta
Um mal-entendido comum: esperar três dias não significa manter conexão pendurada por três dias.
Cada verificação abre a conexão, pergunta e fecha, em cerca de um segundo. Entre uma tentativa e a próxima, que podem ser horas, não existe conexão nenhuma. A espera acontece no intervalo, não dentro da chamada.
Isso importa porque o desenho oposto, o de segurar a requisição esperando o órgão responder por dentro, é o que trava o processamento de outros clientes na mesma fila. É a diferença entre um agendamento e um recurso preso.
O que acontece quando o documento finalmente chega
Ele chega e muda coisas que já foram entregues. É a parte do problema que só aparece depois que tudo o mais funciona.
O farol daquela linha pode virar. O resumo automático precisa ser refeito, porque foi escrito sobre um conjunto incompleto. E se o cliente usa relatório automático, o relatório já saiu, sem aquela peça.
Aqui existe uma decisão de produto, não de engenharia: quem paga a reconsolidação tardia. A posição que consideramos correta é que não se cobra. A análise já foi paga, o atraso é do fornecedor, e cobrar de novo produz uma cobrança que o cliente não pediu, por um recálculo que ele não pode ter solicitado, porque ele nem estava olhando.
Duas armadilhas na implementação disso, e as duas custam caro:
O que perguntar a quem opera a sua coleta
Por que isso é decisão de arquitetura, e não detalhe
A tentação em todo projeto é tratar a fonte assíncrona como exceção: um caso especial, com um código especial, ao lado do fluxo normal.
Funciona até a segunda fonte assíncrona. Depois vira duas exceções, cada uma com o seu prazo, o seu jeito de expirar e o seu jeito de avisar. E o dia em que uma fonte rápida virar lenta, porque o órgão mudou o processo, o caso especial não cobre.
O caminho que se sustenta é o oposto: fonte que responde na hora é o caso particular de uma fonte que responde depois, com prazo próximo de zero. Cinco minutos e três dias passam pelo mesmo código, mudando um número declarado.
Na nossa operação isso vale hoje para mais de 58 órgãos e bases, e é o que permite conectar uma fonte nova declarando o comportamento dela, em vez de abrir mais uma exceção.
Se a sua operação depende de alguma fonte que devolve protocolo antes do documento, vale mapear como o seu processo atual trata a espera, o que ele escreve no lugar do resultado que ainda não existe e o que acontece com o que já foi entregue quando o dado chega.
