Garante reprocessamento de colecoes com falha#99
Merged
Conversation
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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?
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.