Entiende el estado de las tareas en Rivya, la reserva de credits, el envío al proveedor, los callbacks, el polling, el historial, las notificaciones y los fallos.

Usa esta guía cuando necesites entender qué ocurre después de enviar una tarea de generación de imagen, video o audio en Rivya.

Explica en un solo lugar los estados de tarea, la reserva de credits, la finalización por parte del proveedor, el historial, las notificaciones y el manejo de tareas fallidas.

Los estados reales de una tarea

El ciclo de vida asíncrono actual de generación usa cuatro estados visibles:

WAITING
GENERATING
SUCCESS
FAILED

Esos estados se guardan en ai_task y se reutilizan en Studio, el historial, el dashboard y el flujo de notificaciones.

Qué ocurre cuando envías una tarea

1. Rivya válida la solicitud

Antes de que algo llegue a un proveedor, Rivya comprueba:

que el modelo exista
que la generación directa esté habilitada para ese modelo
que el entorno de ejecución esté basado en tareas asíncronas
que la longitud del prompt sea válida
que los parámetros del formulario estén normalizados
que los archivos de referencia coincidan con lo que acepta el modelo

Algunos modelos tienen reglas extra. Por ejemplo, el aislamiento de audio requiere un archivo de audio subido y verificación de duración.

2. Rivya crea el registro de tarea

Rivya crea primero una entrada ai_task, con estado WAITING.

Ese registro guarda el modelo, la categoría, el prompt, los params, los credits reservados, el tipo de billing y, más tarde, el resultado o el estado de fallo.

3. Los credits se consumen antes del envío al proveedor

Esto es importante: para la generación asíncrona, Rivya gasta los credits de la tarea antes de enviar el trabajo al proveedor.

Si los credits son insuficientes:

la tarea se marca como fallida
el servicio upstream nunca se llama
puede crearse una notificación de credits insuficientes

4. Se crea el trabajo del proveedor

Si hay credits disponibles, Rivya envía la tarea al servicio upstream correspondiente y guarda el ID de tarea upstream.

En ese punto, el estado pasa a GENERATING.

Cómo Rivya conoce el resultado

Rivya admite dos rutas de finalización:

callback del proveedor en entornos con callbacks habilitados
actualización de estado y polling cuando la finalización por callback no está disponible

La ruta de callback también verifica la firma del webhook antes de finalizar una tarea.

Si llega un callback antes de que el resultado del proveedor esté completamente listo, Rivya puede posponerlo e intentarlo de nuevo revisando el estado del proveedor.

Ruta de éxito

Cuando la tarea termina con éxito, Rivya:

guarda las URL de resultado
establece el estado en SUCCESS
liquida la tarea
deja la salida disponible en el historial de generación
crea una notificación de generación exitosa

Por eso una imagen o un video terminados siguen visibles después de salir de la página.

Ruta de fallo

Cuando una tarea falla, Rivya:

guarda el mensaje de error
establece el estado en FAILED
reembolsa credits cuando el fallo ocurrió después de la reserva y debe revertirse
crea una notificación de generación fallida para revisión duradera

Esto es distinto de un toast temporal. El fallo pasa a formar parte del registro de la cuenta.

Dónde ves el estado de la tarea

La misma tarea puede aparecer en varios lugares:

el Studio activo mientras sigue en ejecución
Historial después de liquidarse
Centro de notificaciones para resultados importantes
/dashboard en generaciones recientes

Ese estado compartido es una de las razones por las que el producto se siente coherente en lugar de descartable.

En qué se diferencia Chat

Chat también es facturable, pero no usa el mismo registro de tareas asíncronas. Los turnos de chat se guardan como:

sesiones de chat
mensajes de chat

Para modelos de chat basados en tokens, Rivya puede reservar credits primero y luego liquidar el importe final cuando vuelve el uso real. Si el importe final es menor, la diferencia se reembolsa.

Así que la regla general es:

la generación de imagen, video y audio usa ai_task
chat usa sesiones guardadas y liquidación a nivel de mensaje

Sigue leyendo

Lista de revisión de estado de tarea

Cuando una generación sea confusa, lenta, falle o no aparezca, comprueba:

Identifica primero el tipo de tarea: liquidación de chat, imagen, video, audio o chat respaldado por herramientas.
Comprueba si los credits se reservaron antes del envío al proveedor o se liquidaron después del uso.
Busca el callback del proveedor, el resultado del polling, el elemento del historial y la notificación antes de asumir que el resultado se perdió.
Separa los fallos que el usuario puede corregir de los fallos del proveedor o de infraestructura.
Confirma si una tarea fallida debería revertir credits antes de volver a ejecutar el mismo prompt.

Revisa antes de ejecutar de nuevo

Revisa de nuevo cuando el mismo prompt siga fallando, una tarea permanezca en progreso demasiado tiempo, los credits parezcan consumidos sin salida o estés a punto de enviar una ejecución duplicada más pesada.

Guía del ciclo de vida de tareas en Rivya