Divide task dispatch articles em duas task dispatch articles e task harvest articles

[robertatakenaka]

O que esse PR faz?

Refatora o pipeline de seleção e processamento de artigos:

• Reescreve ArticleIteratorBuilder (article/controller.py), removendo o
  __iter__ único e substituindo por métodos explícitos from_pid_provider,
  from_article, from_article_source e from_harvest, cada um recebendo
  o filtro exclusivo da sua fonte.
• Desacopla ArticleSource do modelo legado AMArticle: remove o FK
  am_article e adiciona os campos pid e collection (article/models.py
  • migração correspondente).
• Simplifica add_pid_provider/request_xml/request_pid, reduzindo
  logging redundante e centralizando o tratamento de erro.
• Divide task_dispatch_articles em duas tasks: task_harvest_articles
  (coleta externa via OPAC/ArticleMeta) e task_dispatch_articles
  (despacho sequencial de article_source → pid_provider → article).
• Ajusta article/wagtail_hooks.py aos novos campos de ArticleSource.
• Atualiza bigbang/tasks_scheduler.py para agendar as novas tasks e
  remover as obsoletas.
• Simplifica Journal.select_items (journal/models.py), removendo o
  registro de UnexpectedEvent para queryset vazio.
• Documenta e agrupa os status de PidProviderXML em
  pid_provider/choices.py.
• Adiciona testes unitários: test_article_iterator_builder.py e
  test_article_pipeline.py, com mocks (unittest.mock) e supressão de
  logging do OpenSearch.

Onde a revisão poderia começar?

Sugiro começar por article/controller.py (o ArticleIteratorBuilder
reescrito), depois article/models.py (mudanças em ArticleSource), e
por fim article/tasks.py para ver como as novas tasks consomem o builder.
Os testes em article/tests/ ajudam a entender o comportamento esperado
de cada método.

Como este poderia ser testado manualmente?

1. Aplicar a migração 0050_remove_articlesource_am_article_and_more em
   ambiente de homologação e conferir que os dados existentes de
   ArticleSource não foram perdidos (verificar pid/collection
   preenchidos onde aplicável).
2. Rodar task_harvest_articles manualmente com uma coleção pequena e
   confirmar que os documentos coletados disparam
   task_process_article_pipeline corretamente.
3. Rodar task_dispatch_articles e verificar nos logs/Flower que cada
   artigo é despachado uma única vez, mesmo quando elegível por mais de
   uma fonte (article_source, pid_provider, article).
4. Rodar a suíte de testes:

make django_bash

 python manage.py test article.tests --keepdb

5. Conferir no admin/Wagtail (ArticleSourceSnippetViewSet) que as
   colunas e filtros exibem pid/collection no lugar de am_article.

Algum cenário de contexto que queira dar?

Esta é uma refatoração estrutural sem mudança de escopo funcional externo
esperado — o objetivo é eliminar duplicidade de processamento e reduzir
acoplamento com AMArticle. A migração remove um FK, então é importante
validar em homologação antes de subir para produção. Nenhuma nova
dependência externa foi introduzida.

Screenshots

N/A (mudanças de backend/pipeline, sem impacto visual além do admin
listado acima).

Quais são os tickets relevantes?

• Relacionado à issue de refatoração do pipeline de artigos (ver issue
  vinculada acima).

Referências

• N/A

---

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

Seção obrigatória, referência NSI.04 - Norma de Desenvolvimento Seguro.

• Manipula dados sensíveis/pessoais (LGPD)?
  [ ] Sim [x] Não
  N/A — os campos alterados (pid, collection) são identificadores
  bibliográficos/institucionais, não dados pessoais.

• Altera autenticação, autorização, controle de acesso ou sessão?
  [ ] Sim [x] Não

• Introduz/atualiza/remove dependências de terceiros?
  [ ] Sim [x] Não
  Nenhuma dependência de terceiros foi adicionada, atualizada ou removida.

• Validado pelo pipeline de segurança (SonarQube/Trivy)?
  [ ] Sim [ ] Não — justificar
  Link do job: (preencher com o link do pipeline após execução)

• Concatena/monta/executa comandos SQL, HTML ou JS a partir de entrada externa?
  [ ] Sim [x] Não
  Todas as consultas usam o ORM do Django (filtros via Q/F e kwargs),
  sem SQL bruto ou interpolação de entrada externa.

• Expõe novos endpoints, telas ou serviços?
  [ ] Sim [x] Não
  Não há novos endpoints; apenas ajuste de colunas/filtros no admin
  Wagtail existente (ArticleSourceSnippetViewSet).

• Algum segredo/senha/chave/token adicionado ao código-fonte?
  [ ] Sim [x] Não

[patymori]

Migrações do article

Article Sources

[patymori]

Atualizar documentação com as exceções possíveis no lugar de "False".

[patymori]

Resultado da execução da suite de testes:

[patymori]

Aqui não deveria ter todos os parâmetros de task_harvest_article?

[patymori]

❌ esta referencia à variável item dá erro, pois a declaração dela está dentro do try

[patymori]

Execução de task_harvest_articles manualmente com coleção pequena

✔️ documentos coletados disparam task_process_article_pipeline

Execução de task_dispatch_articles

kwargs para execução:

{"username": "scielo", "user_id": null, "collection_acron_list": ["cic"], "journal_acron_list": null, "from_pub_year": "2026", "until_pub_year": "2026", "from_date": null, "until_date": null, "force_update": false, "export_to_articlemeta": false, "auto_solve_pid_conflict": false, "article_source_status_list": ["completed"], "proc_status_list": ["DONE"], "data_status_list": ["completed"]}

❌ A seguinte exceção ocorreu no log do conteiner:

 INFO 2026-07-31 16:06:28,025 strategy 11 138039802255168 Task article.tasks.task_dispatch_articles[a4834b9d-8761-4c48-923c-c20a2dc50a13] received
 ERROR 2026-07-31 16:06:28,082 models 63 138039802255168 Cannot resolve keyword 'pub_date_year' into field. Choices are: aop_pid, article, article_pub_year, articlesource, available_since, collections, created, creator, creator_id, current_version, current_version_id, elocation_id, events, fixpidv2, fpage, fpage_seq, id, issn_electronic, issn_print, lpage, main_doi, number, origin_date, other_pid, other_pid_count, pkg_name, proc_status, pub_year, registered_in_core, suppl, updated, updated_by, updated_by_id, v2, v3, volume, xmlversion, z_collab, z_links, z_partial_body, z_surnames
 Traceback (most recent call last):
   File "/app/article/tasks.py", line 842, in task_dispatch_articles
     for item_kwargs in item_iterator:
   File "/app/article/controller.py", line 426, in from_pid_provider
     PidProviderXML.objects.filter(q, **filters)
   File "/usr/local/lib/python3.11/site-packages/django/db/models/manager.py", line 87, in manager_method
     return getattr(self.get_queryset(), name)(*args, **kwargs)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/local/lib/python3.11/site-packages/django/db/models/query.py", line 1493, in filter
     return self._filter_or_exclude(False, args, kwargs)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/local/lib/python3.11/site-packages/django/db/models/query.py", line 1511, in _filter_or_exclude
     clone._filter_or_exclude_inplace(negate, args, kwargs)
   File "/usr/local/lib/python3.11/site-packages/django/db/models/query.py", line 1518, in _filter_or_exclude_inplace
     self._query.add_q(Q(*args, **kwargs))
   File "/usr/local/lib/python3.11/site-packages/django/db/models/sql/query.py", line 1646, in add_q
     clause, _ = self._add_q(q_object, can_reuse)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/local/lib/python3.11/site-packages/django/db/models/sql/query.py", line 1678, in _add_q
     child_clause, needed_inner = self.build_filter(
                                  ^^^^^^^^^^^^^^^^^^
   File "/usr/local/lib/python3.11/site-packages/django/db/models/sql/query.py", line 1526, in build_filter
     lookups, parts, reffed_expression = self.solve_lookup_type(arg, summarize)
                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/local/lib/python3.11/site-packages/django/db/models/sql/query.py", line 1333, in solve_lookup_type
     _, field, _, lookup_parts = self.names_to_path(lookup_splitted, self.get_meta())
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/local/lib/python3.11/site-packages/django/db/models/sql/query.py", line 1806, in names_to_path
     raise FieldError(
 django.core.exceptions.FieldError: Cannot resolve keyword 'pub_date_year' into field. Choices are: aop_pid, article, article_pub_year, articlesource, available_since, collections, created, creator, creator_id, current_version, current_version_id, elocation_id, events, fixpidv2, fpage, fpage_seq, id, issn_electronic, issn_print, lpage, main_doi, number, origin_date, other_pid, other_pid_count, pkg_name, proc_status, pub_year, registered_in_core, suppl, updated, updated_by, updated_by_id, v2, v3, volume, xmlversion, z_collab, z_links, z_partial_body, z_surnames
 INFO 2026-07-31 16:06:28,140 base 63 138039750842112 POST http://opensearch:9200/core-logs-dev-2026.07.31/_doc [status:201 request:0.041s]

[pitangainnovare]

Continuei a validação da PR #1460 executando o pipeline de artigos de ponta a ponta, desde a coleta até a atualização de disponibilidade. Além de atender aos comentários da revisão, essa execução revelou algumas regressões que não apareciam nos testes isolados.

Contexto e relação com outras PRs

A PR #1460 continua a consolidação do pipeline iniciada pela PR #1402, separando agora a coleta externa (task_harvest_articles) do despacho das fontes internas (task_dispatch_articles) e desacoplando ArticleSource de AMArticle.

Ela também precisa preservar comportamentos introduzidos pela PR #1453, especialmente filtro por periódico, stop e o estado NOT_PUBLIC. A PR #1404 ainda está aberta e possui sobreposição nos parâmetros verify, issn e stop; provavelmente precisará ser conciliada ou atualizada depois desta PR.

Alterações acrescentadas nesta continuação

1. Migração segura de ArticleSource

A migração original removia am_article sem copiar seus dados para os novos campos. Ela agora:

• adiciona pid e collection antes de remover o relacionamento;
• copia os valores do AMArticle associado quando ele existe;
• usa PidProviderXML.v2 como fallback de pid;
• usa a coleção do PidProviderXML somente quando existe exatamente uma;
• processa o backfill em lotes de 1.000 registros;
• não escolhe arbitrariamente uma coleção quando há ambiguidade.

A análise em homologação encontrou 7.385 ArticleSource, apesar de o ambiente possuir aproximadamente 590 mil Article. Havia 7.362 vínculos com PidProviderXML, todos com v2; 7.343 tinham uma única coleção e 19 tinham duas. A projeção é preencher 7.362 PIDs e 7.343 coleções, preservando NULL nos casos sem fonte ou com coleção ambígua.

2. Correções no ArticleIteratorBuilder

• PidProviderXML passa a ser filtrado por pub_year.
• Article passa a ser filtrado por pub_date_year.
• Foi removido o select_related("pid_provider") de ArticleSource, pois esse relacionamento não existe.

Isso cobre também o FieldError de pub_date_year registrado na revisão durante a execução de task_dispatch_articles.

3. Comentários da revisão

Foram atendidos os três apontamentos formais:

• a documentação de bulk_export_articles_to_articlemeta agora descreve os retornos e as exceções;
• o agendamento de task_harvest_articles agora contém journal_acron_list e stop;
• item e params são inicializados antes do bloco que pode falhar, evitando que UnboundLocalError esconda a exceção original.

O contexto registrado em UnexpectedEvent também foi completado, e task_process_article_pipeline passou a relançar a exceção depois do registro para que o Celery sinalize a falha corretamente.

4. Regressões encontradas no dispatch real

O teste integrado revelou três problemas adicionais:

• BaseLegacyRecord.get apagava todos os registros sem url e data. Essa limpeza veio da PR #1260, onde esses registros eram tratados como órfãos, mas no pipeline atual ela apagava AMArticle válidos recém-gerados. A exclusão global foi removida.
• A transição NOT_PUBLIC → PENDING, prevista pela PR feat: adiciona status NOT_PUBLIC para evitar requisições a documentos despublicados #1453 quando um documento volta a ser público, havia se perdido na refatoração de ArticleSource.update; ela foi restaurada.
• Article.check_availability retornava True quando já havia disponibilidades, mas não chamava mark_as_available, deixando o artigo em COMPLETED. Agora ele volta corretamente para PUBLIC.

Foram adicionados testes de regressão para os três casos.

Validação

Foi executada uma coleta limitada a três documentos. Depois de carregar o fascículo ausente, o dispatch concluiu o fluxo, preservou os três AMArticle, deixou os três PidProviderXML em DONE, associou cinco URLs de disponibilidade a cada artigo e não criou novos UnexpectedEvent. O caso de estado COMPLETED também foi reproduzido e passou a terminar em PUBLIC.

Os testes direcionados do iterator, das tasks, da exportação e dos modelos passaram localmente, incluindo o teste com banco para garantir que AMArticle.get não apague registros. O diff também passou em git diff --check.

As alterações foram separadas em cinco commits:

• 544ea9d0 — preservação de pid e collection na migração;
• 66de6c73 — filtros e consultas do ArticleIteratorBuilder;
• 90e1d667 — tratamento de falhas das tasks;
• 2044adc9 — parâmetros do agendador;
• 824c9a3b — regressões de processamento e publicação.

Estado atual do CI

Os checks do GitGuardian e Snyk passaram. O job pytest do GitHub Actions falhou antes de executar os testes porque o runner não possui o comando docker-compose. O linter falhou porque pre-commit --all-files tentou reformatar muitos arquivos preexistentes fora do escopo desta PR. Esses dois pontos de infraestrutura/baseline ainda precisam ser avaliados; não correspondem às falhas funcionais reproduzidas e corrigidas nesta continuação.