Guía de troubleshooting de Rivya
Soluciona problemas de Rivya con envío de chat, subidas, tareas de generación atascadas, resultados faltantes, pagos, credits, historial y notificaciones.
Última revisión el 2026/04/28
Usa esta guía de troubleshooting cuando el chat, las subidas, las tareas de generación, el historial, las notificaciones, los credits o el estado de billing de Rivya no se comporten como esperas.
Cuando Rivya parece roto, la forma más rápida de corregirlo es decidir qué capa está fallando realmente.
La mayoría de los problemas caen en uno de cinco lugares:
acceso e inicio de sesión
desajuste entre modelo e input
estado de tarea asíncrona
estado de wallet o pago
búsqueda de trabajo guardado
Esa división es mucho más útil que tratar todo como un "bug" genérico.
1. Chat no envía
Si chat no se ejecuta realmente, revisa primero las causas simples:
quizá sigues en un flujo público de landing page y necesitas iniciar sesión antes de enviar
el borrador del mensaje puede estar vacío
la sesión guardada puede no haberse cargado correctamente
Si el problema parece específico de una sesión, vuelve a abrir la conversación desde el historial en lugar de adivinar en qué ruta estabas.
Si la tarea es estrecha y repetitiva, también puede ser más limpio reiniciar desde una entrada de herramienta en lugar de seguir en un hilo amplio de chat normal.
2. Una generación no empieza
Si una generación de imagen, video o audio falla antes de empezar de verdad, las causas habituales son:
falta contenido obligatorio del prompt
un formulario de audio de estilo diálogo está incompleto
el modelo seleccionado requiere un archivo de referencia y no se proporcionó ninguno
la cuenta no tiene credits suficientes
Ahora mismo, los credits insuficientes pueden hacer fallar la ejecución antes de que el servicio upstream se llame. Por eso una sensación de "no pasó nada" puede dejar igualmente un registro fallido real y una notificación.
3. Las subidas fallan
Las subidas dependen del modelo, no de la categoría.
Eso significa:
no todos los modelos de una categoría aceptan los mismos tipos de referencia
no todos los modelos aceptan la misma cantidad de archivos
los límites de tamaño y tipo se aplican antes de la solicitud real de generación
Si una subida falla, revisa:
si el modelo admite ese tipo de archivo
si ya alcanzaste el límite actual de archivos de referencia
si el tipo o tamaño del archivo infringe las reglas actuales de subida
Si el flujo de trabajo es limpieza o aislamiento de audio, recuerda que las rutas de audio subido son estructuralmente distintas de TTS o generación de voz empezando desde prompt.
4. Tarea atascada en progreso
Las ejecuciones de imagen, video y audio son tareas asíncronas en Rivya.
Los estados visibles son:
WAITINGGENERATINGSUCCESSFAILED
Si una tarea parece atascada, no mires solo la página actual.
Revisa también estas superficies:
el Studio activo
generaciones recientes en
/dashboard
Algunas tareas terminan por callback y otras por polling o refresh. Así que "sigue generando" no significa por sí solo "perdida". A menudo significa que la tarea todavía espera a que el resultado final upstream se asiente.
5. Una tarea falló
En Rivya, los fallos normalmente se conservan en lugar de ocultarse.
Una tarea fallida puede conservar:
el propio estado fallido
un mensaje de error
estado de reembolso, cuando los credits reservados deben revertirse
una notificación de generación fallida
Eso significa que el siguiente paso correcto suele ser:
leer el estado de fallo
decidir si el problema fue credits, prompt o desajuste de input
volver a ejecutar solo después de corregir esa causa específica
No trates cada fallo como un problema temporal de UI.
6. El resultado parece haber desaparecido
Normalmente el resultado no desapareció. Está en la superficie equivocada.
Usa el historial cuando la pregunta sea:
¿Qué hice o discutí?
Usa Centro de notificaciones cuando la pregunta sea:
¿Qué evento importante de cuenta o flujo de trabajo ocurrió?
La regla general es:
chat vuelve al historial de chat
imagen, video y audio vuelven al historial de generación
los eventos de billing y credits suelen verse con más claridad en notificaciones
7. El estado de pago parece antiguo
Si el checkout terminó pero el wallet o el estado de billing aún parecen desactualizados, sigue la ruta de billing antes de asumir que el pago se perdió.
El flujo actual del producto es:
completar checkout
volver por
/paymentdejar que el producto haga polling y refresque el estado de billing o wallet
revisar
/settings/billingo/settings/credits
Las notificaciones también pueden conservar resultados de billing, así que vale la pena revisarlas cuando el estado de la cuenta parece desincronizado.
8. Dónde revisar primero
Usa este atajo:
Studio actual: trabajo en vivo en progreso
Historial: resultados y conversaciones guardados
Centro de notificaciones: eventos operativos que ya ocurrieron
/settings/billing: estado de suscripción/settings/credits: saldo de wallet, packs, vencimiento y transacciones
La mayoría de la confusión viene de revisar primero la capa equivocada.
Sigue leyendo
Lista de triage de troubleshooting
Elige el primer lugar a revisar antes de repetir la misma acción:
Chat no envía: revisa inicio de sesión, estado de sesión, disponibilidad de modelo y comportamiento de credits.
Las subidas fallan: revisa tipo de archivo, tamaño, soporte del modelo y si la tarea realmente necesita un archivo.
La generación está atascada: revisa el estado de la tarea, los callbacks del proveedor, el polling, el historial y las notificaciones.
Billing parece desactualizado: revisa el retorno de Checkout, la liquidación de webhook, los ajustes de billing y los ajustes de credits.
Los resultados parecen faltar: revisa el tipo correcto de historial y si la tarea realmente se completó.
Revisa antes de escalar
Escala solo después de poder nombrar el área de cuenta, el task id o contexto de pago, el resultado esperado, el resultado real y el último estado visible. Eso convierte el soporte en diagnóstico en lugar de conjeturas.