- Navios
- 26 de agosto de 2026 às 03:33 UTC
- Autor
- Kamo
- Enviar
- 27d3200
Encontrar 1 (Critical): uma reivindicação de perda de um evento de Stripe redimido provou que existia uma linha, não que a tentativa anterior terminou. A alegada linha deixada para trás por uma falha transitória (Yugabyte 40001, a Hikari tempo limite, uma corrida de restrição única) parecia idêntico a um genuíno duplicado, então a redelivery respondeu 200 e Stripe permanentemente Parei de tentar novamente um dinheiro escrito que nunca aterrou. Adicionado **************************** (os seus próprios REQUISITOS NOVO lido) por isso uma alegação de perda é julgado sobre se processado realmente virou para true; uma linha não processada agora joga **************************** em vez de voltar, então o O controlador responde 500 e a janela de repetição de três dias do Stripe permanece aberta. Encontrando 2 (Importante): markProcessed descartou sua contagem de linhas. A atualização de linha zero foi invisível e deixou o evento silenciosamente não processado Para sempre, sem nada falhar em lado nenhum. Agora afirma exatamente uma linha foi atualizado e lança de outra forma; o javadoc registra o Yugabyte raciocínio snapshot-isolation que torna isso seguro hoje e frágil se um repositório lido é sempre adicionado antes da reivindicação. Encontrar 4 (Minor): o controlador registrou a assinatura ausente-Stripe- header case no ERROR, o mesmo que um verdadeiro missing-secret configuração incorrecta. Esse objetivo é público e acessível à internet, então qualquer chamador poderia gerar linhas ERROR sob demanda, omitindo o Cabeçalho. WebhookNotConfiguredException agora carrega uma chamadaCaused flag; o controlador registra warn para a caixa do cabeçalho e reserva ERROR para O caso que é realmente nosso para corrigir. Testes: fixados em ambas as direções da nova porta de reclamação comportamentalmente (StripeWebhookClaimGateTest, com uma carga real assinada pelo HMAC) e via source- shape (StripeWebhookIdempotencyTest); a marca Processed asserção de contagem de linha comportamentalmente com um repositório simulado *************** e o WARN/ERROR dividir comportamentalmente através de uma lista de logbackAppender **************************** Verificados todos os três são carga de carga, revertendo cada correção por sua vez, confirmando o correspondentes novos testes ir vermelho, em seguida, restaurar e confirmar verde. Suíte completa: 208 testes, 0 falhas, 0 erros (até 193 a 674fa0f).