Resumo

  • A interrupção de rede de 9 de outubro e a falha dos pools de banco no dia 10 foram incidentes diferentes, mas ambas atingiram dependências compartilhadas da execução.
  • Algumas execuções com falhas internas permaneceram em Running; o handler onFailure e funções-pai aguardando o resultado não receberam aviso. Os clientes tiveram de cancelar ou reproduzir os runs.

“Execução durável” promete preservar progresso quando um processo espera ou falha. Essa promessa depende de mais do que checkpoints: onde fica o estado do run? Quais contas compartilham a mesma fila? Qual estado é registrado quando uma dependência interna falha? Quem descobre que a execução não vai continuar sozinha? O relatório da Inngest sobre os dias 9 a 11 de outubro torna essas perguntas concretas.

Às 21:05 UTC de 9 de outubro, um fornecedor perdeu a conectividade entre seu data center e os demais centros da Inngest, além do acesso de saída à Internet. A explicação preliminar do fornecedor foi um erro durante uma mudança na configuração de proteção contra DDoS. A Inngest informou que ainda aguardava o relatório completo, portanto não tratou a causa como conclusiva. A conectividade voltou às 21:49. No dia seguinte, os dois pools PgBouncer diante do banco de dados primário perderam todas as conexões às 14:00 UTC e novamente às 15:30. A programação de execuções e o processamento das filas pararam para a maioria das contas.

Uma mitigação trouxe o serviço de volta, mas introduziu atrasos intermitentes, especialmente nas funções cron, até a programação voltar aos pools originais às 04:17 UTC de 11 de outubro. As rotas dos gateways foram aprimoradas no dia 12. Eram falhas distintas, com mecanismos e caminhos de recuperação próprios.

A primeira falha mostrou como uma fronteira local pode afetar trabalhos fora daquele local. A Inngest disse operar em três data centers. Uma conta podia ser processada em um centro enquanto seu estado ficava em outro; o banco central de contas e configurações e os pools de conexão estavam com um terceiro fornecedor. Com o caminho entre os centros interrompido, alguns workers não podiam consultar dados da conta ou salvar o estado da execução. Contas processadas em outros lugares também paravam se o estado necessário estivesse no local isolado.

O trabalho que falhava ainda formou um grande acúmulo no pipeline de eventos compartilhado e atrasou contas sem dependência direta daquele centro. Contas com pipeline dedicado não foram afetadas. O pipeline comum ampliou o raio de impacto além da dependência original.

O segundo incidente teve outra mecânica. Segundo a Inngest, consultas com prazos curtos interagiram com o cancelamento do cliente e o PgBouncer. Algumas consultas ainda aguardavam uma conexão quando o prazo expirava. O driver fechava a conexão do cliente; mais tarde, o PgBouncer executava a consulta abandonada, mas fechava a conexão com o banco em vez de devolvê-la ao pool. Como conexões novas eram abertas uma a uma, elas eram destruídas mais rápido do que podiam ser repostas.

Isso coincidiu com os picos cron no início e no fim da hora, quando o volume de consultas quase triplicava, e com uma nova série de consultas implantadas antes do fim de semana que começou a falhar em grande escala. Reiniciar os pools não era confiável, e aumentar seu limite não acelerava a abertura de novas conexões.

A mitigação introduziu outro caminho de rede. A mudança para pools operados pelo fornecedor junto ao banco restabeleceu o processamento entre 16:10 e 16:25 UTC. Essa rota, porém, atravessava gateways NAT que descartavam algumas conexões sem sinalização. Consultas podiam ficar paradas por até 16 minutos antes de falhar, com atrasos especialmente visíveis nas funções cron. A Inngest retornou a programação cron aos pools originais às 04:17 UTC do dia 11 e melhorou o roteamento dos gateways no dia 12. Uma mitigação também é uma alteração de topologia: pode retirar um gargalo e criar um novo limite temporal menos observável.

A lacuna mais importante apareceu na transição de estado. A Inngest afirmou que falhas internas consumiram as tentativas configuradas. Quando um passo falhava definitivamente por um erro interno, alguns runs permaneciam Running em vez de mudar para Failed. O handler onFailure não era acionado, e uma função-pai à espera por step.invoke não recebia o erro. A empresa disse que essas execuções não continuariam sozinhas e que os clientes precisavam cancelá-las ou reproduzi-las. Recuperar os workers não prova que cada processo de negócio interrompido alcançou um estado terminal.

Isso difere da retomada normal de um workflow. A documentação da Inngest explica que o resultado de um passo concluído pode ser reutilizado na retomada e que passos são repetidos individualmente. Mas o replay descrito no relatório começa o run do início; passos já concluídos podem rodar outra vez. Não há evidência de que pagamentos, mensagens ou gravações tenham sido duplicados. Ainda assim, os operadores precisam inspecionar o trace e verificar se os efeitos podem se repetir com segurança. Um serviço externo pode aceitar uma operação antes de o motor registrar seu resultado; uma nova tentativa pode repetir a chamada.

A orientação de idempotência da Inngest recomenda chaves estáveis para esses efeitos. Checkpoints preservam progresso interno, mas não tornam cada efeito externo exatamente uma vez.

A Inngest disse que já implantou correções: consultas que aguardam uma conexão não são mais canceladas junto com o cliente; falhas internas permanentes marcam a execução como falha; se não for possível ler o estado naquele momento, o trabalho permanece na fila e retoma assim que o estado estiver disponível. O roteamento e as atualizações da página de status também foram aprimorados. A consolidação em um único data center ainda estava em andamento. O relatório não descreve a topologia final nem seu mecanismo independente de recuperação.

Fontes