Corrige o valor de pkg_names / pkg_name_list usando pkg_name_variations

[robertatakenaka]

O que esse PR faz?

Fale sobre o propósito do pull request, como por exemplo: quais problemas ele soluciona ou quais features ele adiciona.

Concentra em pid_provider a adaptação ao formato de dados exposto pelo packtools, sem alterar a versão fixada no Core.

• As variações de pkg_name passam a ser obtidas de xml_with_pre.pkg_name_variations, que já concentra os nomes depreciados/alternativos do pacote. O cálculo local é mantido como fallback (captura de AttributeError), preservando a compatibilidade com versões de packtools que ainda não expõem o atributo.
• Os dados de entrada registrados em response["input_data"] passam a ser normalizados por fix_xml_with_pre_data(xml_with_pre), no lugar do acesso direto a xml_with_pre.data, tanto no fluxo de registro quanto no de consulta.

Inclui ainda dois ajustes de configuração de ambiente:

• RUN_ASYNC passa a ter valor padrão 1, tornando a execução assíncrona o comportamento padrão sem depender de definição explícita da variável de ambiente.
• Em ALLOWED_HOSTS do ambiente local, o IP fixo 192.168.1.98 é substituído por core.local, removendo um endereço vinculado a uma máquina específica.

Onde a revisão poderia começar?

Indique o caminho do arquivo e o arquivo onde o revisor deve iniciar a leitura do código.

pid_provider/query_params.py — método que monta as variações de pkg_name e função fix_xml_with_pre_data. Em seguida, pid_provider/models.py (usos de fix_xml_with_pre_data no registro e na consulta). Por último, config/settings/base.py e config/settings/local.py.

Como este poderia ser testado manualmente?

Estabeleça os passos necessários para que a funcionalidade seja testada manualmente pelo revisor.

1. Com a versão de packtools que expõe pkg_name_variations, registrar e consultar um XML pelo pid_provider e conferir que as variações de nome (incluindo nomes depreciados) são consideradas na busca.
2. Repetir o mesmo fluxo com a versão de packtools que não expõe o atributo e confirmar que o fallback mantém o comportamento atual.
3. Conferir que response["input_data"] é gerado sem erro nos dois fluxos (registro e consulta) e que o conteúdo está normalizado.
4. Subir o ambiente local sem definir RUN_ASYNC e confirmar que as tarefas são enfileiradas de forma assíncrona.
5. Acessar a aplicação local por core.local e confirmar que a requisição não é rejeitada por host inválido.

Algum cenário de contexto que queira dar?

Indique um contexto onde as modificações se fazem necessárias ou passe informações que contextualizam o revisor a fim de facilitar o entendimento da funcionalidade.

O Core permanece fixado em packtools 4.16.11 para evitar impacto mais amplo nos requirements. A compatibilidade com o formato de dados da versão 4.17.1 é absorvida no próprio código do pid_provider (fix_get_article_data, fix_get_data_to_compare e agora fix_xml_with_pre_data), de modo que a atualização do pacote possa ocorrer depois, sem retrabalho. A delegação das variações de pkg_name segue a mesma linha: usar a fonte canônica do pacote quando ela existir, em vez de reconstruí-la localmente.

Screenshots

Quando aplicável e se fizer possível, adicione screenshots que remetem à situação gráfica do problema que o pull request resolve.

Não aplicável — as mudanças são de backend e configuração, sem efeito visual.

Quais são os tickets relevantes?

Indique uma issue à qual o pull request faz relacionamento.

Referências

Indique as referências utilizadas para a elaboração do pull request.

• Atributo pkg_name_variations de XMLWithPre (packtools).
• Formato de dados de packtools 4.17.1 em relação a 4.16.11.

---

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):

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 — a alteração em ALLOWED_HOSTS afeta apenas o settings de desenvolvimento local, não expondo novos serviços.

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)

[pitangainnovare]

Há testes quebrados.
É necessário fazer o pkg_name_varitions (um set) ser json-safe.

[pitangainnovare]

Todos os pontos foram corrigidos.