Configura filas de parsing e atualiza seed de logs

[pitangainnovare]

O que esse PR faz?

Desacopla o processamento de logs das categorias de tamanho fixadas no código e permite selecionar a fila de parsing em cada tarefa periódica.

• adiciona parse_queue_name ao fluxo Search -> Validation -> Parsing;
• usa DEFAULT_PARSE_QUEUE=parse_small quando a fila não é informada;
• torna as coleções de cache de metadados, liberação do cache e particionamento anual configuráveis por ambiente;
• preserva os valores atuais como padrão;
• atualiza o seed com Data, Preprints e as fontes BunnyNet canônicas de Venezuela e West Indies;
• mantém fontes legadas registradas como inativas sem alterar o estado dos e-mails;
• remove tarefas agregadoras e de demonstração que não fazem parte da operação;
• organiza os workers do Compose local em processos separados por fila;
• atualiza a versão para 2.3.7.

Onde a revisão poderia começar?

Comece por log_manager/tasks.py, onde a fila é propagada pelo pipeline. Depois veja metrics/services/log_parsing_jobs.py, config/settings/base.py e config/collections.py.

Como este poderia ser testado manualmente?

1. Configure uma Periodic Task para [Log Pipeline] 1. Search Logs (Manual) na fila load.
2. Informe parse_queue_name nos kwargs, por exemplo parse_tiny, e confirme que Validation encaminha o parsing para essa fila.
3. Omita parse_queue_name e confirme o uso de DEFAULT_PARSE_QUEUE, cujo padrão é parse_small.
4. Execute o seed e confira os diretórios ativos de Data, Preprints, Venezuela e West Indies, bem como as fontes legadas inativas.
5. Defina YEAR_PARTITIONED_COLLECTIONS e confirme que somente essas coleções recebem o ano no nome dos índices mensais e anuais.

Validações automatizadas executadas:

• 225 passed, 2 skipped;
• Black, isort e flake8 nos arquivos alterados;
• sintaxe Bash dos starts;
• validação dos arquivos Compose;
• inicialização e encerramento de um worker local em fila isolada;
• gitleaks nos commits.

Algum cenário de contexto que queira dar?

Os workers de parsing passaram a ser implantados por fila (tiny, small, medium, large e xlarge). A fila representa uma decisão operacional do deployment ou da Periodic Task e não deve continuar vinculada a uma classificação fixa da coleção no código.

Nenhum arquivo de configuração ou inicialização de produção faz parte deste PR.

Screenshots

Não aplicável.

Quais são os tickets relevantes?

Não há ticket associado.

Referências

Não aplicável.

---

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): não altera dependências nem imagem-base; gitleaks local aprovado e o CI do PR executará as verificações configuradas no repositório.

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)