Documentación de Rivya AI

Guía del ciclo de vida de tareas en Rivya

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

Última revisión el 2026/04/28

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 provider, el historial, las notificaciones y el manejo de tareas fallidas.

Los estados reales de una tarea

El ciclo de vida async 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 provider, Rivya comprueba:

  • que el modelo exista
  • que la generación directa esté habilitada para ese modelo
  • que el runtime esté basado en tareas async
  • 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 provider

Esto es importante: para la generación async, Rivya gasta los credits de la tarea antes de enviar el trabajo upstream.

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 provider

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 provider 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 provider esté completamente listo, Rivya puede posponerlo e intentarlo de nuevo revisando el estado upstream.

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
  • History 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 async de tarea. 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 provider o se liquidaron después del uso.
  • Busca el callback del provider, el resultado de polling, el elemento de 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 provider 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.

Tabla de contenido