- Navios
- 6 de agosto de 2026 às 19:04 UTC
- Autor
- Kamo
- Enviar
- 8db077c
Armazenamento de objetos é balde-por-associação (cada leitor resolve img.getAssocId().getBucket()), mas a deduplicação é escopo ORG-wide ou GLOBALly e Assim, cruza associações. Registro ExistingDocument anexou um ImgDat existente a um nova associação sem carregar nenhum bytes, deixando uma Img que apontou para um balde que nunca tinha recebido — cada leitura (download, stream, thumbnail, convert- pdf) falhou com "O balde especificado não existe" / NoSuchKey e Surgiu como um 500. Acesse a aba do membro Docs: um fw9.pdf carregado para recursos de RH e recarregado lá manteve seus bytes apenas em image-hr-resources, então abri-lo no editor de e-sign deu "Falhou em obter PDF: 500" enquanto /hr/resources abriu o mesmo arquivo multa. Copiar os objetos do dat (original, versão convertida, miniaturas) para o alvo balde no registo. Copiar em vez de ler de onde quer que eles vivam mantém associações independentes: excluir o documento fonte não deve apagar o Dedurou um. Um dado cujos bytes existem em nenhum lugar agora falha o registro em vez de criando um documento que 500s em cada leitura. Também declarar commons-io diretamente: com.vonage:client arrasta em 2.5, que sombreou o 2.15.1 Spring Boot gerencia, e Tika 2.9.2 precisa 2.7+ — em 2.5 o MimeTypeDetectionUtils static inicializer dies with NoClassDefFoundError.