Verificación y problemas habituales - Nuxt
Un evento de prueba controlado
export default defineEventHandler(() => {
throw createError({ statusCode: 500, statusMessage: 'Error de control DockRay' });
});Visita esta ruta una vez y bórrala en cuanto la prueba funcione. La entrada debería aparecer en el panel, en la sección Errores del proyecto al que apunta el token.
Problemas habituales
Credenciales en la parte equivocada de la configuración
El token y la clave deben quedar en la mitad privada de la configuración de runtime - mediante NUXT_RAY_TOKEN/NUXT_RAY_PRIVATE_KEY, o directamente bajo la clave ray en nuxt.config.ts. Puestas bajo runtimeConfig.public.ray acaban en el paquete de cliente - el mismo riesgo que una clave de Next.js con prefijo NEXT_PUBLIC_.
Los errores 404 no aparecen en el panel
Es lo previsto. Solo se notifican los códigos 5xx - createError({ statusCode: 404 }) y cualquier otro 4xx es un resultado normal, no una avería.
Un error de un componente Vue no aparece en el panel
Comprueba si browser.enabled está activado y si la página cargó realmente el plugin de cliente - Vue traga los errores de los componentes en su propio manejador, así que sin los hooks vue:error/app:error conectados, un error nunca llega a window.onerror ni, desde ahí, al colector.
Faltan transacciones pese a una configuración correcta
Dos causas independientes: tracesSampleRate a 0, o la ruta coincide con una de las entradas de ignorePaths (por defecto /_nuxt, /__nuxt, /health, /metrics) y se omite a propósito.
Los errores de JavaScript del navegador no llegan
La ruta de Nitro solo existe si browser.enabled estaba definido en tiempo de compilación - activarlo solo con una variable de entorno en tiempo de ejecución no basta, el módulo necesita saberlo durante setup(). Comprueba también si el servidor tiene NUXT_RAY_TOKEN y NUXT_RAY_PRIVATE_KEY definidos: la ruta sigue respondiendo 202 de todos modos, simplemente no reenvía nada.
Un despliegue en worker (Cloudflare) no notifica
El módulo lee el evento por el mismo camino en Node y en workers, así que no hace falta una segunda ruta de código - si aun así no llega nada, comprueba si las variables NUXT_RAY_* están realmente disponibles en el entorno de ese despliegue concreto, no solo en local.
Un mismo error se parte en muchas entradas
El panel agrupa por la huella sha256(token del proyecto + tipo + mensaje). Un identificador de pedido o de usuario incrustado en el mensaje de la excepción parte un error en mil filas.
El panel responde 200 pero no aparece el evento
Una respuesta 200 {"success": false} significa que la cuenta ha agotado su cupo mensual de errores. La integración no lo trata como una avería, y hace bien. El cupo se ve en el panel de la cuenta; hasta fin de mes se calcula a partir del consumo registrado, así que borrar errores no lo reinicia.
Sigue sin funcionar
Repasa la lista de comprobación de falta de datos y, si no ayuda, escríbenos. Indica el nombre del proyecto, la versión de la integración y la hora aproximada de la prueba: acorta el camino a la respuesta.