- Navios
- 27 de agosto de 2026 às 05:24 UTC
- Autor
- Kamo
- Enviar
- f848f39
Um membro enviou um .wav de 11 MB para um bate-papo, tem "Não é possível invocar ObjectWriteResponse.etag() porque a resposta é nula", enviou-a novamente e a o segundo entregue instantaneamente — apontando para bytes que nunca foram armazenados. Cada tentar jogar 500'd com "Object não existe". Dois defeitos em série. minio-java 8.5.7 tem um terceiro resultado para putObject que não é um resultado nem uma exceção: quando um upload MULTIPART falha e o cancelamento compensador então SUCCEEDS, S3Base.putMultipartObjectAsync cai de seu bloco de captura e retorna a resposta ainda nula em vez de rejogar (bytecode offsets 147→171→226→228). A leitura do seu etag lançou um NullPointerException, que não está na captura por nós lista — por isso escapou ao circuito failover e os restantes nós MinIO nunca foram Tentei. Tratar um resultado de escrita nulo como um nó falhado: o loop move- se e se cada nó falhar, o chamador é informado de que o objeto não foi armazenado. A fila sobreviveu. guardarContent Endereçado escreve o ImgDat com isMissing=true ANTES que os bytes vão para o armazenamento, que é deliberado — um acidente deve deixar uma linha que admite que não tem nada. Mas nenhuma pesquisa de dedup verificou aquela bandeira, então os mortos linha foi uma partida perfeitamente boa, e o caminho de streaming não é @Transactional assim Nada voltou atrás. Cada consulta dedup agora corresponde apenas ao conteúdo publicado, e uma falha de upload capturada descarta a linha que acabou de escrever. Apenas uploads multipartes podem falhar desta forma, por isso foi invisível para pequenos arquivos e Esperou exactamente pelos grandes que um membro a maioria das mentes perdeu.