Validación Automática en Segundo Plano (Asíncrona)

[germankay]

El archivo se sube normalmente, pero el sistema inicia un proceso de validación inmediatamente después de la carga.

• Funcionamiento: Al completar la carga, se dispara un background job (usando CKAN Worker / RQ). El recurso puede quedar marcado con un estado "Pendiente de Validación" y, una vez finalizado, se actualizan los metadatos con el resultado.

• ¿Se sube el CSV si hay errores?: Sí. El archivo permanece en el sistema, pero se le adjunta un "Sello de Calidad" o un reporte de errores visible.

• Pros: No interrumpe el flujo de carga; es la opción más escalable para archivos de gran volumen.

• Contras: Permite la existencia temporal de datos con errores en el repositorio.

[germankay]

Primera versión de Validación Automática en Segundo Plano para recursos CSV en CKAN

Objetivo

Implementar una primera versión de validación automática en segundo plano para recursos CSV en CKAN, de modo que al crear o actualizar un recurso se dispare una validación asíncrona y el resultado quede reflejado en los campos de validación del recurso.

Pasos de implementación

1. Detectar la carga o actualización de un recurso CSV

Modificar o extender las acciones resource_create y resource_update para identificar cuándo el recurso cargado o actualizado es un archivo CSV.

La lógica debería verificar, por ejemplo:

• format == "CSV" o equivalente normalizado
• que el recurso sea apto para validación
• opcionalmente, que sea un archivo subido localmente si esa es una restricción actual de la validación

2. Marcar el recurso como “Pendiente de Validación”

Una vez guardado el recurso, actualizar sus extras para reflejar que la validación todavía no fue ejecutada, por ejemplo:

• validation_status = "pending"
• validation_error_count = null
• validation_errors = null

Esto permite que la interfaz muestre inmediatamente que el recurso está esperando ser validado.

3. Disparar un job en segundo plano

Luego de marcar el recurso como pendiente, lanzar un job asíncrono utilizando alguna opción de procesamiento en background:

• CKAN Worker

El job debe recibir al menos el resource_id y encargarse de ejecutar la validación sin bloquear la respuesta del usuario.

4. Ejecutar la validación dentro del job

El proceso en background debe reutilizar la lógica de validación existente, llamando a la función actual resource_validate.

De esta forma, la validación automática mantiene el mismo comportamiento que la validación manual ya implementada con Frictionless.

5. Actualizar el recurso con el resultado

Al finalizar la validación, el job debe actualizar los campos del recurso con el resultado obtenido, por ejemplo:

• validation_status
• validation_error_count
• validation_errors

Esto dejará persistido si el recurso resultó válido, inválido o si ocurrió un error durante el proceso.

6. Mostrar el estado y el reporte en la interfaz

Ajustar la UI para que pueda mostrar correctamente los distintos estados de validación, incluyendo:

• pending
• valid
• invalid
• error (si se decide usar este estado)

También debe mostrarse el reporte final o los errores cuando la validación termine.

Resumen técnico

• Agregar un hook en resource_create y resource_update para detectar recursos CSV.
• Marcar el recurso recién creado o actualizado con estado pending.
• Lanzar un job en segundo plano con el resource_id.
• Ejecutar resource_validate dentro del job asíncrono.
• Guardar el resultado de la validación en los extras del recurso.
• Ajustar la interfaz para mostrar el estado pendiente y el resultado final.

Alcance de esta primera versión

Esta primera versión busca resolver el flujo básico de validación automática sin bloquear la carga del recurso. Más adelante se podrían agregar mejoras como:

• evitar múltiples jobs duplicados para el mismo recurso
• reintentos automáticos ante fallos temporales
• historial de validaciones
• cola priorizada
• notificaciones al usuario cuando la validación termine