Construir pipelines batch confiables

Podés decir, para cada fuente, cuándo fue su último éxito y cuántas corridas seguidas lleva fallando, sin abrir un log.

Podés correr tu pipeline dos veces seguidas y comprobar que el estado de la base es idéntico, y sabés decir cuál es la clave que lo garantiza.

Podés nombrar la clave natural de tu fuente y decir qué pasa cuando llega un registro con fecha vieja, sin tener que correr el pipeline para averiguarlo.

Podés recorrer el histórico completo de una fuente y quedarte tranquilo de que correrlo dos veces no duplica nada.

Tenés un test que falla a propósito cuando le metés un dato malo, y sabés dónde queda ese dato después de fallar.

El feed de Iceberg se cayó a las pocas horas de haberlo verificado a mano. Verificar una fuente una vez no dice nada sobre mañana: lo que hace falta es last_success_at, consecutive_failures y una regla de degradación a las tres corridas. Aparte, los reintentos con backoff exponencial sin jitter sincronizaban a fuentes distintas en el mismo instante, que es el fallo que el backoff venía a evitar.

El hash de contenido se calculaba sobre el JSON crudo de GitHub, que trae download_count por asset. Cambiaba con que alguien descargara un archivo, sin release nuevo, así que cada corrida guardaba una fila nueva. La garantía tiene que vivir en un constraint, no en la disciplina del código que escribe.

El primer diseño del descubrimiento de herramientas contaba menciones con un mention_count que se incrementaba en cada corrida: volver a procesar el mismo artículo lo contaba de nuevo, así que el umbral para proponer un candidato se alcanzaba solo con el paso del tiempo. Se reemplazó por una tabla con UNIQUE(candidate_id, article_url), donde contar dos veces el mismo artículo es imposible por constraint. Este lo agarré en la revisión del plan, antes de escribir el código; la vez anterior, con el hash de raw_fetches, me enteré en producción.

El backfill de releases traía 30 por herramienta y paraba ahí, porque nadie estaba paginando la API de GitHub, que sí devuelve el historial completo. No fallaba: devolvía menos y quedaba en verde. La primera corrida con paginación trajo 913 releases nuevos en una sola pasada. Un hueco de historia no levanta ninguna alerta; hay que ir a buscarlo.

El validador de anclaje se probó con citas inventadas a propósito, porque un validador que nunca rechaza nada no está validando. La otra mitad la encontró una auditoría posterior: stg_article_mentions y stg_summaries no tenían un solo test y el grano compuesto no estaba cubierto en ningún lado, así que la suite estaba en verde sobre modelos que nadie chequeaba. El complemento es la cuarentena: lo que no valida se guarda con su error, porque descartarlo en silencio pierde el dato y también la señal de que la fuente cambió.