Verification and common problems - Symfony

Checking that the bundle is active

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

The first command confirms the bundle is registered, the second shows which values are actually in effect once the environment variables are resolved. That settles most of the "I configured it and nothing happens" cases.

A controlled event

Call captureMessage() from a command or a controller and check whether the event turned up in the panel under Errors. The environment should match %kernel.environment%.

Common problems

Nothing arrives in the panel

Check, in order: whether debug:config ray shows a filled-in token and private_key (rather than an unresolved %env(...)%), whether both belong to the same project, whether the container cache is fresh (php bin/console cache:clear), and whether the server allows outbound HTTPS.

The panel filled up with 404 errors

In Symfony a 404 is an exception. Add NotFoundHttpException to ignore_exceptions. The same goes for access denials if they are a normal outcome in your application.

An exception is reported, but not the right one

ExceptionListener sits at priority -128, so it reports the exception that survived the application's listeners. If your own listener converts an exception into another and rethrows it, the panel shows the second one - and that matches what the request actually died on.

User data is missing

UserListener registers only when symfony/security-core is installed, and it runs on kernel.controller. An exception thrown before the controller - in the firewall or in another kernel.request listener - will not have a user yet.

Console command errors are missing

ConsoleErrorListener needs symfony/console in the project and listens to console.error. A command that catches its own exception and returns an exit code without rethrowing never fires that event - report by hand through ray.hub there.

Transactions are missing

Transactions are only produced when traces_sample_rate is above zero, they cover main requests only (not sub-requests) and they close on kernel.terminate. Check ignore_transactions as well - a path prefix matching your route disables timing for that whole branch of URLs.

A Messenger worker does not pick up a configuration change

The hub is a container singleton, and a worker reads the configuration at startup. After changing ray.yaml or .env.local, restart the workers (php bin/console messenger:stop-workers).

The panel answers 200 but there is no event

A 200 {"success": false} response means the account has used up its monthly error quota. The integration does not treat that as a failure - and rightly so. You can see the quota on the account dashboard; until the end of the month it is counted from recorded usage, so deleting errors does not reset it.

Still not working

Work through the troubleshooting checklist, and if that does not help, write to us. Include the project name, the integration version and roughly when you ran the test: it shortens the way to an answer.