Skip to content

Garante reprocessamento de colecoes com falha#99

Merged
rondinelisaad merged 1 commit into
masterfrom
codex/python3-14-migration
Jul 3, 2026
Merged

Garante reprocessamento de colecoes com falha#99
rondinelisaad merged 1 commit into
masterfrom
codex/python3-14-migration

Conversation

@rondinelisaad

Copy link
Copy Markdown
Member

O que esse PR faz?

Adiciona uma fila persistente para colecoes que falham durante o processamento. Quando uma colecao falha, o run.sh registra o acronimo em failed_collections.queue no diretorio de logs; na proxima execucao, essas colecoes sao priorizadas antes da lista normal e removidas da fila quando forem processadas com sucesso. Isso evita que falhas transitorias, como indisponibilidade do ArticleMeta thriftserver, facam uma colecao ficar sem nova tentativa ate alguem intervir manualmente.

Onde a revisão poderia começar?

Comece por run.sh, nas funcoes normalize_collection_list, load_failed_collections, record_failed_collection e clear_failed_collection, e depois veja o fluxo em main. A documentacao complementar esta em README.md na secao Kubernetes / Argo.

Como este poderia ser testado manualmente?

  1. Definir LOG_DIR para um diretorio temporario e criar um failed_collections.queue com um acronimo valido, por exemplo arg-AR. 2. Executar run.sh com uma lista que nao comece por essa colecao e observar no log a mensagem de reprocessamento das colecoes pendentes. 3. Simular falha de uma colecao e confirmar que o acronimo e registrado em failed_collections.queue. 4. Executar novamente com a colecao corrigida e confirmar que ela e removida da fila apos sucesso.

Algum cenário de contexto que queira dar?

O workflow do Argo executa colecoes em sequencia e, em ambiente agendado, usa EXIT_ON_FAILURE=false para nao bloquear proximas execucoes. Antes desta mudanca, uma falha apos as tentativas locais apenas seguia para a proxima colecao e dependia da proxima rodada completa ou de acao manual. A fila persistente usa o volume de logs ja montado para manter memoria das colecoes pendentes entre execucoes.

Screenshots

Nao aplicavel; mudanca sem interface grafica.

Quais são tickets relevantes?

Nao informado.

Referências

PR 98 aplicado antes desta mudanca: https://github.com/scieloorg/processing/pull/98/commits. Contexto operacional: erro de conexao ConnectionResetError ao consultar ArticleMeta thriftserver.

O que esse PR faz?

Adiciona uma fila persistente para colecoes que falham durante o processamento. Quando uma colecao falha, o run.sh registra o acronimo em failed_collections.queue no diretorio de logs; na proxima execucao, essas colecoes sao priorizadas antes da lista normal e removidas da fila quando forem processadas com sucesso. Isso evita que falhas transitorias, como indisponibilidade do ArticleMeta thriftserver, facam uma colecao ficar sem nova tentativa ate alguem intervir manualmente.

Onde a revisão poderia começar?

Comece por run.sh, nas funcoes normalize_collection_list, load_failed_collections, record_failed_collection e clear_failed_collection, e depois veja o fluxo em main. A documentacao complementar esta em README.md na secao Kubernetes / Argo.

Como este poderia ser testado manualmente?

1. Definir LOG_DIR para um diretorio temporario e criar um failed_collections.queue com um acronimo valido, por exemplo arg-AR. 2. Executar run.sh com uma lista que nao comece por essa colecao e observar no log a mensagem de reprocessamento das colecoes pendentes. 3. Simular falha de uma colecao e confirmar que o acronimo e registrado em failed_collections.queue. 4. Executar novamente com a colecao corrigida e confirmar que ela e removida da fila apos sucesso.

Algum cenário de contexto que queira dar?

O workflow do Argo executa colecoes em sequencia e, em ambiente agendado, usa EXIT_ON_FAILURE=false para nao bloquear proximas execucoes. Antes desta mudanca, uma falha apos as tentativas locais apenas seguia para a proxima colecao e dependia da proxima rodada completa ou de acao manual. A fila persistente usa o volume de logs ja montado para manter memoria das colecoes pendentes entre execucoes.

Screenshots

Nao aplicavel; mudanca sem interface grafica.

Quais são tickets relevantes?

Nao informado.

Referências

PR 98 aplicado antes desta mudanca: https://github.com/scieloorg/processing/pull/98/commits. Contexto operacional: erro de conexao ConnectionResetError ao consultar ArticleMeta thriftserver.
@rondinelisaad rondinelisaad merged commit 74aacaf into master Jul 3, 2026
4 of 5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant