Criar validação de valores aceitáveis para pub-date do tipo pub

[robertatakenaka]

Validação: data de pub não deve estar no futuro além de uma tolerância

Contexto / Problema

O artigo 0102-6720-abcd-39-e1948 (PID S0102-67202026000100609) não estava sendo exibido em produção (SciELO BR), mesmo após reprocessamento sem erros nos relatórios. O artigo já estava correto em QA e Homolog:

• QA: http://homolog.xml.scielo.br/scielo.php?script=sci_arttext&pid=S0102-67202026000100609&lng=en&nrm=iso&tlng=en
• Homolog: http://homolog.scielo.br/scielo.php?script=sci_arttext&pid=S0102-67202026000100609&lng=en&nrm=iso&tlng=en

Causa raiz identificada: o XML do pacote tinha um erro de digitação — a data de pub foi informada como 2029 (deveria ser 2026). O ano de collection estava correto (2026).

O OPAC 5 possui um filtro que só exibe artigos com data de publicação (pub) ≤ data atual — mecanismo usado para artigos com "data de estreia" agendada. Como o pub estava em 2029, o artigo ficou retido silenciosamente:

• Não gerou nenhum erro no relatório de reprocessamento;
• O artigo simplesmente não aparece na consulta pública, sem log associado;
• As validações atuais só cobrem inconsistência no ano de collection, não no ano de pub — por isso o erro passou despercebido.

Observação importante: a data de pub é imutável — representa a primeira vez que o documento foi processado/entrou no sistema. Não é um problema de reprocessamento; o valor errado já estava gravado desde a entrada original do XML.

Objetivo

Criar uma validação automática que impeça esse tipo de erro de passar despercebido para produção, sinalizando como erro pacotes com pub inconsistente.

Ponto central da correção

A validação essencial é comparar a data de pub com a data atual (hoje) — não pub com collection.

O collection serve apenas para classificar/interpretar o cenário (adiantado, atrasado, retrospectiva), mas quem efetivamente detecta o erro relatado é a distância entre pub e a data real do sistema.

Regras de negócio

1. pub no futuro (checagem primária, resolve o bug relatado)

• pub não pode estar no futuro além de uma pequena tolerância (poucos dias, a confirmar).
• Se ultrapassar → ERRO (foi exatamente o caso do 2029).

2. pub muito anterior ao collection

• Tolerância máxima: 12 meses de diferença (a confirmar com a equipe editorial).
• Além disso → ERRO.
• Ou seja: não existe "retrospectiva para trás" ilimitada — mesmo coleções antigas, o pub não deveria ficar muito atrás do próprio collection a que pertence.

3. pub posterior ao collection, mesmo que por muitos anos

• Permitido — cobre o caso de coleção retrospectiva (ex.: periódico publicando hoje seu acervo histórico: collection=1908, pub=2026).
• Único limite real é a Regra 1: pub não pode ultrapassar a data atual.

4. pub == collection

• Sempre OK.

Tabela-resumo

Caso	Condição	Interpretação	Resultado
A	pub > hoje (+ tolerância)	Provável erro de digitação	ERRO
B	collection − pub > 12 meses	Pub muito anterior ao collection	ERRO
C	collection == pub	Publicação em dia	OK
D	pub > collection, mesmo que por muitos anos, e pub ≤ hoje	Coleção retrospectiva legítima	OK
E	pub < collection, diferença ≤ 12 meses	Adiantamento normal	OK

Pseudocódigo de referência

from datetime import date, timedelta
def validar_datas(ano_collection, data_pub, hoje,

tolerancia_meses_atras=12, tolerancia_dias_futuro=0):

"""

ano_collection: int, ano do fascículo/coleção

data_pub: date, data de publicação do documento

hoje: date, data atual do sistema

"""
# Regra 1: pub não pode estar no futuro além de pequena tolerância
if data_pub > hoje + timedelta(days=tolerancia_dias_futuro):
    return "ERRO: pub no futuro — provável erro de digitação"

# Regra 2: pub não pode ser muito anterior ao collection (máx. 12 meses)
limite_atras = date(ano_collection, 1, 1) - timedelta(days=30 * tolerancia_meses_atras)
if data_pub < limite_atras:
    return "ERRO: pub muito anterior ao collection (> 12 meses)"

# pub > collection por muitos anos é permitido (retrospectiva),
# desde que não viole a Regra 1 (pub <= hoje)
return "OK"

Onde implementar

• Definir se a validação entra no fluxo de ingestão do XML (packtools) ou no reprocessamento (scms-upload / pid_provider)
• Adicionar ao relatório de erros existente, para não passar despercebido como neste caso
• Parametrizar as tolerâncias (tolerancia_dias_futuro, tolerancia_meses_atras) — não deixar hardcoded
• Confirmar com a equipe editorial os valores exatos de tolerância (dias no futuro / 12 meses no passado)

Testes a cobrir

• pub = hoje → OK
• pub = poucos dias no futuro (dentro da tolerância) → OK
• pub = muito no futuro (ex.: 2029 quando hoje é 2026) → ERRO
• pub = collection (mesmo ano) → OK
• pub até 12 meses antes do collection → OK
• pub mais de 12 meses antes do collection → ERRO
• pub muitos anos depois do collection (retrospectiva), mas ≤ hoje → OK
• pub muitos anos depois do collection, mas > hoje → ERRO

Critério de aceite

• Qualquer pacote com pub no futuro além da tolerância definida gera erro visível no relatório de validação/reprocessamento, independente do valor de collection.
• Pacotes com pub até 12 meses antes do collection continuam passando normalmente.
• Pacotes com coleção retrospectiva (pub muito posterior ao collection, mas ≤ hoje) continuam passando normalmente.
• O erro do tipo relatado (pub = 2029 em vez de 2026) passa a ser detectado automaticamente, sem depender de investigação manual.

Caso de referência

• Artigo: 0102-6720-abcd-39-e1948
• PID: S0102-67202026000100609
• Erro: pub = 2029 (deveria ser 2026); collection = 2026 (correto)

ABCD v39 lote 1126 - Arquivo 0102-6720-abcd-39-e1948

0102-6720-abcd-39-e1948.zip

Relatório HML
Relatório XC