Verificación y problemas habituales - Symfony

Comprobar que el bundle está activo

php bin/console debug:container ray.hub
php bin/console debug:config ray

El primer comando confirma que el bundle está registrado; el segundo muestra qué valores rigen de verdad una vez resueltas las variables de entorno. Eso resuelve la mayoría de los casos de «lo he configurado y no pasa nada».

Un evento controlado

Llama a captureMessage() desde un comando o un controlador y comprueba si el evento aparece en el panel, en la sección Errores. El entorno debería coincidir con %kernel.environment%.

Problemas habituales

No llega nada al panel

Comprueba en orden: si debug:config ray muestra token y private_key rellenos (y no un %env(...)% sin resolver), si ambos pertenecen al mismo proyecto, si la caché del contenedor está fresca (php bin/console cache:clear) y si el servidor permite HTTPS saliente.

El panel se ha llenado de errores 404

En Symfony un 404 es una excepción. Añade NotFoundHttpException a ignore_exceptions. Lo mismo para las denegaciones de acceso si en tu aplicación son un resultado normal.

Se notifica una excepción, pero no la correcta

ExceptionListener está en la prioridad -128, así que informa de la excepción que sobrevivió a los listeners de la aplicación. Si un listener propio convierte una excepción en otra y la relanza, el panel muestra la segunda, y eso coincide con aquello con lo que la petición realmente murió.

Faltan los datos del usuario

UserListener solo se registra si está instalado symfony/security-core, y se ejecuta en kernel.controller. Una excepción lanzada antes del controlador - en el firewall o en otro listener de kernel.request - aún no tendrá usuario.

Faltan errores de los comandos de consola

ConsoleErrorListener necesita symfony/console en el proyecto y escucha console.error. Un comando que captura su propia excepción y devuelve un código de salida sin relanzarla no dispara ese evento: informa a mano mediante ray.hub.

Faltan transacciones

Las transacciones solo se generan con traces_sample_rate mayor que cero, cubren únicamente las peticiones principales (no las subpeticiones) y se cierran en kernel.terminate. Revisa también ignore_transactions: un prefijo de ruta que coincida con la tuya desactiva la medición de toda esa rama de direcciones.

Un worker de Messenger no recoge un cambio de configuración

El hub es un singleton del contenedor y un worker lee la configuración al arrancar. Después de cambiar ray.yaml o .env.local, reinicia los workers (php bin/console messenger:stop-workers).

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.