Node-local MinIO + failover template read + ImgDat dedup (fixes new-doc about:blank)

FixDocsService
Navios
30 de junho de 2026 às 23:15 UTC
Autor
Sage
Enviar
9cd1ad0

Criação de novos documentos suspensos ~5 min e a nova aba ficou em aproximadamente:blank. Causa raiz: Os pods DocsService agendados no k3m1 leram o modelo em branco de MinIO no WireGuard IP 10.8.1.1 (k1m1) codificado, que é inacessível de k3m1 (a sobreposição k1m1<->k3m1 WG está baixa). O modelo lido usou um singleton Feijão MinioClient sem tempo limite (Minio SDK padrão 5 min), então crieNewDocument bloqueado indefinidamente; a captura do frontend escreveu o erro no pré- aberto Página em branco. Correcções: - implantação: fonte MINIO CURRENT HOST da API Downward (status.hostIP) assim cada pod usa a instância MinIO local para seu nó, em vez de um IP estático que identifica cada cápsula com o endereço de WireGuard (agora inalcançável). - configmap: ponto MinIO corrente/borda/frio em minio.cluster-services (alcançável de cada nó, suportado pelo k1m1 que contém todos os dados) em vez dos mortos WireGuard IPs — usado como failover por trás do host atual nó-local. - DocumentService: leia o modelo através do failover MinIOStorageService.download() (fresh, timeout-bounded clients + failover de nó) em vez do sem-timeout bruto Feijão MinioClient, então um nó inalcançável falha rapidamente em vez de pendurar. - DocumentService: conteúdo-endereçado dedup de ImgDat. Modelos em branco são bytes idênticos, então uma nova inserção violou idx img dats hash unique no 2o+ document; reutilizar a linha existente através do findByHashCombination (combinando o upload caminhos) e somente upload quando recém-criado. - Remova o feijão singleton não usado.

Todas as alterações

Como o que vês no transporte?

Cada uma dessas atualizações pousa automaticamente em seu espaço de trabalho. Comece grátis e veja crescer semana após semana.

Começar Livre Para SempreVer Preços