Cataloga arquivos de log vazios individualmente

[pitangainnovare]

O que esse PR faz?

Corrige a catalogação de arquivos de log vazios e atualiza a versão da aplicação para 2.4.1.

Arquivos vazios produziam sempre o MD5 d41d8cd98f00b204e9800998ecf8427e. Como o campo LogFile.hash é único, somente o primeiro arquivo vazio era representado no PostgreSQL; os demais eram reencontrados em buscas posteriores, mas associados ao registro canônico já existente e nunca chegavam à validação.

Agora, somente quando o conteúdo descompactado está vazio, o catálogo gera uma identidade determinística baseada em coleção e caminho. Assim, cada arquivo pode ser catalogado e validado individualmente. Arquivos normais continuam usando o hash do conteúdo, sem alteração de comportamento.

A implementação também preserva a recuperação do registro: se um arquivo antes vazio passar a conter dados válidos, o mesmo LogFile volta para CRE, com o hash de conteúdo e os campos de processamento reiniciados.

Onde a revisão poderia começar?

A revisão pode começar em log_manager/services/catalog.py, na identificação de conteúdo vazio e no tratamento unificado dos registros provisórios de catálogo. Em seguida:

• log_manager/file_errors.py: geração das identidades determinísticas;
• log_manager/utils.py: constante correspondente ao hash do conteúdo vazio;
• log_manager/tests/test_catalog.py: cenários de múltiplos vazios, idempotência, validação e recuperação.

Como este poderia ser testado manualmente?

1. Criar dois arquivos .log.gz vazios, com caminhos diferentes, em um diretório ativo de uma coleção.
2. Executar a tarefa de busca sem disparar validação.
3. Confirmar que foram criados dois registros LogFile em CRE, com hashes diferentes.
4. Executar novamente a busca e confirmar que nenhum registro adicional foi criado.
5. Executar a validação sem parsing e confirmar que ambos passam para INV, com probably_date=None.
6. Adicionar conteúdo válido a um dos arquivos e executar novamente a busca.
7. Confirmar que o registro correspondente volta para CRE, sem duplicação de caminho.

Validações automatizadas executadas:

pytest log_manager/tests -q
# 24 passed

isort --check-only log_manager/file_errors.py log_manager/utils.py log_manager/services/catalog.py log_manager/tests/test_catalog.py
black --check log_manager/file_errors.py log_manager/utils.py log_manager/services/catalog.py log_manager/tests/test_catalog.py
flake8 log_manager/file_errors.py log_manager/utils.py log_manager/services/catalog.py log_manager/tests/test_catalog.py
python manage.py makemigrations --check --dry-run
# No changes detected

Algum cenário de contexto que queira dar?

Durante a catalogação histórica da coleção URY, foram encontrados 216 arquivos GZIP válidos, porém vazios. Todos tinham 45 bytes comprimidos, zero bytes descompactados e o mesmo MD5 vazio. Um arquivo vazio antigo de Books já possuía esse hash no banco, impedindo que os arquivos de URY fossem representados e validados.

A alteração não muda o cálculo de hashes dos logs com conteúdo, não altera o parser, não cria tarefas Celery e não requer migration.

Screenshots

Não aplicável.

Quais são os tickets relevantes?

Não há ticket associado.

Referências

Comportamento observado na catalogação histórica dos logs URY em HML.

---

Segurança da informação (NSI.04)

Seção obrigatória. Marque as opções aplicáveis e justifique quando necessário. Referência: NSI.04 - Norma de Desenvolvimento Seguro.

Este PR manipula dados sensíveis ou pessoais (LGPD)?

• Sim — descreva os controles de proteção aplicados (criptografia, mascaramento, anonimização, etc.):
• Não

Este PR altera autenticação, autorização, controle de acesso ou gerenciamento de sessão?

• Sim — descreva o que mudou e por quê:
• Não

Este PR introduz, atualiza ou remove dependências de terceiros?

• Sim — as novas dependências foram verificadas no SBOM/Trivy sem vulnerabilidades críticas/altas em aberto?
  • Verificado e aprovado
  • Pendente / vulnerabilidade aceita com justificativa:
• Não

Este PR foi validado pelo pipeline de segurança (SonarQube / Trivy)?

• Sim — link do job:
• Não aplicável a este PR (justifique): alteração localizada, sem dependências ou novas superfícies externas; o pipeline remoto será executado no PR.

Este PR concatena, monta ou executa comandos SQL, HTML ou JavaScript a partir de entrada externa?

• Sim — confirme que há sanitização/parametrização (prepared statements, escaping, etc.):
• Não

Este PR expõe novos endpoints, telas ou serviços?

• Sim — HTTPS obrigatório está garantido e o acesso segue o princípio de menor privilégio?
• Não

Algum segredo, senha, chave ou token está sendo adicionado ao código-fonte?

• Não, nenhum segredo foi commitado
• Sim (bloquear merge e corrigir antes de prosseguir)