Resumo

  • A OpenAI abriu às 00:55:27 UTC um incidente por taxas elevadas de erro com o código invalid_prompt.
  • A empresa informou mitigação e monitoramento às 01:39:33 e declarou recuperação completa às 02:20:19, encerrando uma linha pública de 1:24:52.
  • O registro não informa o status HTTP; separadamente, o SDK oficial transforma um HTTP 400 real em BadRequestError e não o inclui na repetição comum.
  • Descartar todo invalid_prompt pode perder tarefas válidas, mas reenviar tudo pode duplicar consumo, ativos, notificações ou alterações posteriores.
  • A OpenAI não publicou causa raiz, taxa de falhas, geografia, lista de modelos ou endpoints, volume de requisições nem quantidade de clientes afetados.

Em um fluxo simples, repetir parece barato: a primeira chamada falhou, então basta fazer outra. Em uma cadeia real, a tentativa pode ter consumido tokens, gerado um ativo que a resposta não entregou, atualizado um registro interno ou liberado um passo seguinte. A ausência de uma resposta útil não prova que nenhum efeito ocorreu.

O incidente invalid_prompt torna esse problema mais difícil porque o rótulo aponta para uma falha definitiva do cliente. Sistemas bem-intencionados podem nem guardar o trabalho para nova tentativa. Quando a página oficial mais tarde confirma um incidente do fornecedor, a empresa descobre que não tem uma fila de recuperação — ou que sua única alternativa é repetir sem saber o que já aconteceu.

O custo da primeira tentativa pode permanecer invisível

O registro público diz que houve erros elevados na API, mas não informa se uma chamada rejeitada entrou em processamento, consumiu capacidade faturável ou produziu algum artefato antes de devolver o erro. Também não publica uma política de crédito para o evento.

Por isso, não é possível afirmar que toda falha teve custo financeiro, nem que nenhuma teve. O controle do cliente precisa registrar o identificador da operação comercial separadamente do identificador da tentativa HTTP. Uma operação pode ter uma, duas ou mais tentativas; seu resultado final deve continuar sendo único.

Esse modelo permite comparar uso e cobrança depois. Se uma tarefa foi repetida por causa do incidente, a equipe consegue identificar as duas tentativas, o resultado aceito e qualquer consumo que mereça investigação. Sem essa ligação, o gasto aparece apenas como aumento agregado.

Idempotência precisa chegar até o efeito de negócio

O SDK pode aplicar lógica de repetição no transporte, mas não conhece todo o fluxo que vem depois. Uma resposta de geração pode alimentar um publicador, um sistema de atendimento, uma campanha, uma planilha de decisão ou uma notificação ao cliente.

Mesmo que duas respostas sejam tecnicamente válidas, executar as duas pode criar artigos duplicados, enviar mensagens repetidas ou substituir um arquivo já aprovado. Uma chave estável para a operação, acompanhada de um registro “pendente, concluída, falhou, reconciliada”, reduz esse risco.

Antes de repetir, o operador pergunta se o primeiro efeito pode ser consultado. Se houver um ativo ou registro com aquela chave, a recuperação pode consistir em buscar o resultado, não em gerar outro. Quando não existe consulta possível, a repetição deve ser limitada e o resultado passar por deduplicação antes de liberar etapas posteriores.

O 400 continua fora da repetição automática por um bom motivo

A documentação da biblioteca Python associa o estado 400 a BadRequestError. Ela lista conexão, 408, 409, 429 e respostas iguais ou superiores a 500 entre os casos repetidos automaticamente duas vezes por padrão. A implementação também respeita uma indicação explícita x-should-retry. Essa regra vale quando o cliente realmente recebe 400; o registro do incidente não confirma que esse foi o status.

Incluir todo 400 nessa lista depois deste episódio seria uma reação excessiva. Uma solicitação malformada continuará malformada, aumentará custo e pressão se for enviada repetidamente e poderá esconder um defeito do próprio produto.

O ajuste mais seguro é criar uma exceção temporária baseada em correlação: formato anteriormente válido, aumento anormal, horário dentro do incidente oficial e recuperação confirmada por sondas pequenas. As tarefas entram em quarentena, não em um laço aberto.

A reconciliação precisa separar quatro saldos

Depois das 02:20:19 UTC, quando a OpenAI declarou a recuperação, o cliente ainda precisa contar o que ficou para trás. Há tarefas realmente inválidas; tarefas possivelmente atingidas e nunca repetidas; tarefas repetidas com resultado confirmado; e tarefas cujo primeiro resultado pode existir, mas não foi recebido.

Misturar essas categorias produz dois tipos de prejuízo. No primeiro, trabalho válido permanece perdido porque foi rotulado como erro de entrada. No segundo, a organização repete uma operação já concluída e paga ou executa o efeito novamente.

O identificador de requisição exposto por exceções APIStatusError ajuda a investigar cada tentativa. Um horário UTC, versão do SDK, modelo, endpoint e impressão digital não reversível do formato completam o registro. A impressão digital não deve conter o texto bruto de prompts, credenciais ou dados pessoais.

O aviso de recuperação não mede cada cliente

A página da OpenAI lista APIs como componente afetado e chama o impacto de minor. Ela também explica que as métricas são agregadas entre níveis, modelos e tipos de erro; a experiência individual pode variar.

Assim, 1:24:52 é a extensão do registro oficial, não uma indisponibilidade uniforme. A fonte não permite calcular quantas chamadas falharam, quanto foi cobrado, quais regiões sofreram mais ou quantos clientes precisaram repetir trabalho.

Também não há causa raiz nem status HTTP publicado. Não se sabe por que uma condição do fornecedor apareceu sob invalid_prompt, nem quais modelos e endpoints participaram. Erros de entrada genuínos podem ter acontecido no mesmo período, e atribuí-los todos — ou todos os 400 — à OpenAI seria tão imprudente quanto descartá-los todos como culpa do usuário.

O episódio deixa uma regra econômica clara. A recuperação de uma API paga não termina quando uma nova tentativa devolve sucesso. Ela termina quando a empresa comprova qual operação deveria existir, quantas tentativas consumiu, qual resultado foi aceito e se algum efeito foi duplicado. Entre abandono e repetição cega, a reconciliação é o controle que protege tanto a continuidade quanto o caixa.

Fontes