Skip to content

feat: validación de parquets de runtime como gate (#45)#68

Merged
pablotis merged 7 commits intostagingfrom
feat/issue-45-etl-validation
May 9, 2026
Merged

feat: validación de parquets de runtime como gate (#45)#68
pablotis merged 7 commits intostagingfrom
feat/issue-45-etl-validation

Conversation

@pablotis
Copy link
Copy Markdown
Collaborator

@pablotis pablotis commented May 8, 2026

Summary

Cierra issue #45. Nuevo script ETL/12-validate_paneles_runtime.R con 29 validaciones testthat que corren tras regenerar los parquets de runtime. Si alguna falla, el workflow aborta y prod queda intacta.

Dimensiones cubiertas:

  1. Schema y tipos (31 cols esperadas, drift de eph/arrow).
  2. Cobertura temporal (≥75 dúos trim / ≥65 anual, empieza 2003-T3).
  3. Tamaño y atrición (n>5000 por dúo, ratio anual/trim ∈ [40%, 120%]).
  4. Cross-validation tasas CSV histórico vs parquet on-demand (tolerancia 0.5 pp).

Integración al pipeline:

  • testthat agregado al install de update_eph_data.yml.
  • Step "Validar parquets de runtime" entre 09b y la creación del PR.

Diferido (issue queda abierto):

  • Distribución de variables clave contra INDEC.
  • Regresión bit-a-bit. Ambos requieren datos de referencia versionados.

Test plan

  • Happy path: 29 PASS, exit 0.
  • Caso degradado (umbral inflado para forzar fail): 1 FAIL, script raisea.
  • Próxima ejecución del cron update_eph_data.yml (día 5 del mes) usa el gate.

🤖 Generated with Claude Code

pablotis and others added 7 commits May 3, 2026 13:09
Setup staging environment and improve UI features
Promote staging → master: v0.7.1 + v0.7.2 + v0.7.3 + ROADMAP
Promote staging → master: v0.8.0 (Película + Tasas en Interanual)
Promote staging → master: v0.8.1 (fix selector Película)
Master HEAD venía con GA4_MEASUREMENT_ID <- "" desde el merge de PR #50
(staging → master, 2026-05-03). Ese merge pisó el ID válido de prod
(commit f25f900) sin que se aplicara el git checkout master -- previsto
en el procedimiento de promoción. Resultado: GA4 está roto en producción
desde 2026-05-03 (4 días sin tracking).

Restauro el ID. Al hacerse en este PR de promoción staging → master,
queda atómico: el merge trae las features + tests Y vuelve el tracking
en el mismo deploy.

NOTA: Este archivo seguirá siendo el conflict point en futuros
staging → master. Considerar git attribute merge=ours en master, o
extraer GA4_MEASUREMENT_ID a un archivo separado que solo cambie en
master (mejora futura, no implementada).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Promover staging → master: v0.9.0 + tests + restore GA4
Sprint B · Calidad técnica. Nuevo script ETL/12-validate_paneles_runtime.R
con 29 validaciones testthat que se ejecutan sobre los parquets de
runtime tras regenerarlos. Si alguna falla, el script aborta con exit
status != 0 y el workflow update_eph_data.yml no crea el PR de datos
nuevos: prod queda intacta hasta que se diagnostique.

Cubre 4 dimensiones:

1. Schema y tipos. Las 31 columnas esperadas existen en ambos parquets
   (intertrim + anual), con los tipos correctos (string/double/int32/bool).
   Detecta drift de eph::organize_panels o de la versión del paquete arrow.

2. Cobertura temporal. Mínimo 75 dúos trim / 65 anual, ambos arrancando
   en 2003-T3 (primer dúo histórico tras el cambio de operativo INDEC).
   Si un rebuild deja menos dúos, alerta.

3. Tamaño y atrición. Ningún dúo con n < 5000 (threshold conservador,
   los dúos chicos típicamente tienen ~10k filas). Ratio anual/trim
   promedio ∈ [40%, 120%] basado en el rango histórico observado al
   2026-05-08 (ratio real: 44.5% a 102.9%, mean 88.7%).

4. Cross-validation. Las tasas (Persistencia/Salida/Entrada) calculadas
   on-demand desde el parquet coinciden con las pre-calculadas en
   tasas_*_historico.csv hasta 0.5 pp. Detecta desincronización entre
   los dos pipelines (CSV histórico via 03-update_data, parquet via
   09/09b).

Integración al workflow:
- testthat agregado al install_packages step de update_eph_data.yml.
- Step "Validar parquets de runtime" insertado entre la regeneración
  de 09b y la creación del PR. Solo corre si has_new=='true'.

Implementación notable:
- MultiReporter (ProgressReporter + FailReporter) da feedback visual
  por test pero hace raise al final si alguno falló (FailReporter es
  silencioso por sí solo).
- Constantes de threshold están al inicio del script con comentario
  sobre cuándo recalibrarlas.
- Validado happy path (29 PASS) y degradado (1 FAIL → script exit != 0).

Diferido a iteración futura (issue queda abierto):
- Distribución de variables clave contra corte transversal de INDEC.
- Regresión bit-a-bit (re-correr el ETL produce output idéntico).
  Necesitan datos de referencia que hoy no tenemos versionados.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@pablotis pablotis merged commit 0204c50 into staging May 9, 2026
1 check 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