Errors are not sent to Bugsnag in Laravel 5.6

[grund3g]

Expected behavior

All Errors are sent to Bugsnag

Observed behavior

Only a fraction of the errors are sent to Bugsnag

Version

Laravel 5.6.27 (upgraded from 5.4)

Additional information

config/app.php

.env

App\Exceptions\Handler

All Errors are logged to storage/laravel.log but not sent to Bugsnag.

[grund3g]

It only works if I have APP_DEBUG=true set. Then the bugs are also sent to Bugsnag

[bengourley]

Hi @grund3g, are you setting the release stage to "production"?

If not, based on your BUGSNAG_NOTIFY_RELEASE_STAGES configuration, you will be preventing error reports being sent from any environment that is != "production".

[grund3g]

Hi @bengourley , not explicitly, but as mentioned in the description it should default to the app environment if it is not set ("Leaving this unset will default to using the application environment.") and this is set to APP_ENV=production

Actually, theBUGSNAG_NOTIFY_RELEASE_STAGES=production in the screenshot was just to figure out if it would change anything.

but as mentioned above it is strange that the bugs are sent to bugsnag whenAPP_DEBUG=true

[bengourley]

Ok thanks, just wanted to rule that out.

Is there any more info you can provide? Have you tried making a reduced test case? Does it work for you if you clone our example laravel project?

On Mon, 23 Jul 2018, 17:43 grund3g, notifications@github.com wrote:

Hi @bengourley https://github.com/bengourley , not explicitly, but as mentioned in the description it should default to the app environment if it is not set ("Leaving this unset will default to using the application environment.") and this is set to APP_ENV=production

Actually, theBUGSNAG_NOTIFY_RELEASE_STAGES=production in the screenshot was just to figure out if it would change anything.

but as mentioned above it is strange that the bugs are sent to bugsnag when APP_DEBUG=true

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bugsnag/bugsnag-laravel/issues/311#issuecomment-407123262, or mute the thread https://github.com/notifications/unsubscribe-auth/AAlNK3vH5vieYVRLQjI8dY5wu8mid_KNks5uJf0jgaJpZM4VYidL .

[dwightwatson]

I'm having issues with Bugsnag and Laravel 5.6 as well.

I've pulled down the example Laravel project from this repo, configured by API key and forced some exceptions and they did not show up in my Bugsnag dashboard.

In my app I have the exact same logging configuration as @grund3g, have the service provider registered manually and set my API key using the BUGSNAG_API_KEY environment variable - I have not published the Bugsnag configuration file.

[bengourley]

Can I just confirm that you're using a version of bugsnag-laravel >= v2.14.0? Laravel 5.6 support was added in that version.

[grund3g]

I am currently using v2.14.1

[bengourley]

Ok, thanks. I'll get this looked into.

[bengourley]

I just cloned the example in this repository and navigated to /test – I got the example exception in my dashboard.

Here are the exact steps I followed:

• clone this repo (git clone git@github.com:bugsnag/bugsnag-laravel.git)
• create a Dockerfile in the example/laravel56 directory

  
  FROM php:7
  RUN apt-get update -y && apt-get install -y openssl zip unzip git
  RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
  RUN docker-php-ext-install pdo mbstring

WORKDIR /app COPY . /app RUN composer install

CMD php artisan serve --host=0.0.0.0 --port=8181 EXPOSE 8181

- create `.env` file (`cp .env.example .env`)
- fill out `BUGSNAG_API_KEY` and `APP_KEY` values in `.env`
- build the container (`docker build . -t b-lara-56`)
- run the container (`docker run -p 8181:8181 b-lara-56`)
- navigate to `http://localhost:8181/test`, and see the laravel error page
- see that the "Example exception!" made it through to Bugsnag

Can you confirm whether this is working (or not!) for you?

[grund3g]

I will clone the example repo and test it. Another interesting behavior: I just tried to throw new Exception('Example exception!'); in a controller and I have forgotten to import the Exception.

Nothing on Bugsnag but in my laravel.log: production.ERROR: Class 'App\Http\Controllers\Exception' not found

After importing the Exception I can see the error in Bugsnag.

[bengourley]

Another interesting behavior: I just tried to throw new Exception('Example exception!'); in a controller and I have forgotten to import the Exception.

That sounds like it might be due to order of imports – if this error happened before Bugsnag was imported/initialized then Bugsnag obviously can't handle it. Does that sound plausible with your codebase?

[dwightwatson]

I cloned it earlier today on my work computer and have now tried again on my personal computer. I don't use Docker - instead I just use Laravel Valet - so not a total replication of your process. However, I'm still experiencing the same issue.

What's odd is that it's intermittent - I had this earlier too but didn't mention it because I hadn't narrowed down whether it was my fault or not. However this time the exception only made its way through to Bugsnag on the second page load of /test, and subsequent refreshes didn't trigger additional events.

In addition I've had this deployed to a Heroku server for most of the week on which I've knowingly caused some errors and I've realised they never made it through to Bugsnag either. Still digging in to try and get a better idea of what is going on under the hood.

[bengourley]

What's odd is that it's intermittent - I had this earlier too but didn't mention it because I hadn't narrowed down whether it was my fault or not. However this time the exception only made its way through to Bugsnag on the second page load of /test, and subsequent refreshes didn't trigger additional events.

In addition I've had this deployed to a Heroku server for most of the week on which I've knowingly caused some errors and I've realised they never made it through to Bugsnag either. Still digging in to try and get a better idea of what is going on under the hood.

Do you see anything in the logs when you trigger an exception that doesn't get sent to Bugsnag?

[dwightwatson]

Yeah, it still shows up in laravel.log. Finishing up for the night here now but will continue playing tomorrow to see if I can get any more information.

[grund3g]

That sounds like it might be due to order of imports – if this error happened before Bugsnag was imported/initialized then Bugsnag obviously can't handle it. Does that sound plausible with your codebase?

Not really. I also checked / tested several times the order of the ServiceProvider registration. Currently I have the BugsnagServiceProvider at first place in my providers array in the config/app.php.

I just tried to Bugsnag::notifyError('ErrorType', 'Something bad happened');, but nothing. To be absolutely sure, I also checked the network connections but there is no connection to bugsnag.com.

[grund3g]

What's odd is that it's intermittent - I had this earlier too but didn't mention it because I hadn't narrowed down whether it was my fault or not. However this time the exception only made its way through to Bugsnag on the second page load of /test, and subsequent refreshes didn't trigger additional events.

Just noticed the same here. I've thrown a RuntimeException in a controller. The first time it has been sent to bugsnag, but no matter how many times I cause the error again, nothing is sent to bugsag. Only logged in laravel.log

[grund3g]

Using laravel valet (installed a fresh copy of laravel 5.6.28)

laravel new bugsnagtest
composer require "bugsnag/bugsnag-laravel:^2.0"

followed these instructions: https://docs.bugsnag.com/platforms/php/laravel/ addedBugsnag\BugsnagLaravel\BugsnagServiceProvider::class, to the providers array in app/config.php

added BUGSNAG_API_KEY=your-api-key-here to my .env with an api-key of an new / empty Bugsnag project

updated as mentioned in the docs myconfig/logging.php

and finally as mentioned in the docs Bugsnag::notifyException(new RuntimeException("Test error"));

The error is only sent the first time to bugsnag.

[bengourley]

Please can you send an email to support@bugsnag.com with your organization name, account email address and project you are sending errors to, so that we can take a closer look at that side of things?

[grund3g]

@bengourley thanks for your help! I've just contacted the support.

[sweebee]

I've got the same issue now on a new project.

Laravel 5.6, bugsnag v3.14.1,

APP_ENV=production APP_DEBUG=true

bugsnag.php

'notify_release_stages' => ['production', 'acceptation', 'testing'],

logging.php

'channels' => [
        'stack' => [
            'driver' => 'stack',
            'channels' => ['daily', 'bugsnag'],
        ],

        'single' => [
            'driver' => 'single',
            'path' => storage_path('logs/laravel.log'),
            'level' => 'debug',
        ],

        'daily' => [
            'driver' => 'daily',
            'path' => storage_path('logs/laravel.log'),
            'level' => 'debug',
            'days' => 7,
        ],

        'slack' => [
            'driver' => 'slack',
            'url' => env('LOG_SLACK_WEBHOOK_URL'),
            'username' => 'Laravel Log',
            'emoji' => ':boom:',
            'level' => 'critical',
        ],

        'stderr' => [
            'driver' => 'monolog',
            'handler' => StreamHandler::class,
            'with' => [
                'stream' => 'php://stderr',
            ],
        ],

        'syslog' => [
            'driver' => 'syslog',
            'level' => 'debug',
        ],

        'errorlog' => [
            'driver' => 'errorlog',
            'level' => 'debug',
        ],

        'bugsnag' => [
            'driver' => 'bugsnag',
        ],
    ],

use Bugsnag\BugsnagLaravel\Facades\Bugsnag;
use RuntimeException;
Bugsnag::notifyException(new RuntimeException("Test error"));

returns null and nothing happens in bugsnag.

[designbyjr]

After a thorough look at the bugsnag vendor code is the bugsnag/bugsnag repository that composer downloads for bugsnag-laravel to use and it should be bugsnag/bugsnag namespace not bugsnag.

Could your namespacing be wrong guys? I know people miss things but this seems to be a bit of a problem. @bugsnag

[kattrali]

After a thorough look at the bugsnag vendor code is the bugsnag/bugsnag repository that composer downloads for bugsnag-laravel to use and it should be bugsnag/bugsnag namespace not bugsnag.

@designbyjr That doesn't seem to be the case; the namespace doesn't need to be the same as the vendor path. The bugsnag/bugsnag library contains the primary PHP interface and thus is in the Bugsnag namespace. The bugsnag/bugsnag-laravel package is an extension of that and thus is in the Bugsnag\BugsnagLaravel namespace. If there was an issue with the namespace, it would not be a silent failure.

[grund3g]

@dwightwatson Have you been able to find anything else on your side?

[dwightwatson]

No, haven't been able to narrow it down at all. I wondered if it was somehow related to batch sending but I haven't found anything conclusive. I still find that even when I can trigger an exception to show up in Bugsnag, repeating the exact same steps will not trigger another event. Honestly not sure what's going on.

[dwightwatson]

@grund3g were Bugsnag able to help you at all on your end? Was hoping some progress would be made there.

[grund3g]

@dwightwatson unfortunately not yet but according to the support they are also working on it.

[kingsloi]

I can confirm, we were also affected by this issue. We lost 2 days worth of leads because our db went down (and those alerts different trigger for a separate issue) but our Laravel app was 500'ing but we were not receiving any Bugsnag alerts at all from our production environment.

To confirm this is a production only issue, I renamed my local database incorrectly, hit the webapp a few times on my local environment, look in Bugsnag and low-and-behold, the alerts are there.

I'm forced to look into Bugsnag replacement, as arguably the most important feature of a bug reporting service is to report bugs that occur on production, so for them to be ignored is a pretty serious flaw.

[vladflip]

laravel 5.6.29 bugnang-laravel 2.14.1

We have the same issue on our project. The errors are reported randomly (sometimes does, sometimes doesn't) without any changes in the configuration. Config file is not published. The channel in logging.php is set up according to the website installation doc.

[kattrali]

I've spent some time investigating this issue, and the furthest I've gotten is that using any of the reproduction setups posted above (using Valet, using Docker, using neither and manually php artisan serveing), reports are generally delivered, with two exceptions:

1. Occasionally a request will fail for networking reasons. I observed 5 or 6 in a batch of 900+ requests.
2. Not every error was reported to the simple logger (in storage/logs/laravel.log), but every one which was captured in the simple logger was reported to Bugsnag (with the exception of list item 1 occasionally happening). This number could vary wildly, sometimes missing 8 or 9 errors in a batch of 300, or 120 errors in a batch of 500.

I'm generating errors using the following route config:

<?php

Route::get('/', function () {
    throw new RuntimeException("Something truly terrible");
    return view('welcome');
});

So my next steps are to figure out where the disconnect is happening between when errors occur and when they are logged.

[grund3g]

have continued testing the last days and have now tested the standard php library.

In the register() method in the AppServiceProvider:

$bugsnag = \Bugsnag\Client::make(config('bugsnag.api_key'));
$bugsnag = \Bugsnag\Client::make();
\Bugsnag\Handler::register($bugsnag);

So far, everything's going the way it should be and the errors are reported correctly to bugsnag.

[grund3g]

and unfortunately not! Apparently worked, but now reacts exactly as before

[wsakka]

What @grund3g posted 8 days worked for me (I just had to take out the second line): https://github.com/bugsnag/bugsnag-laravel/issues/311#issuecomment-416376262.

So this is my register method:

public function register()
    {
        $bugsnag = \Bugsnag\Client::make(config('bugsnag.api_key'));
        //$bugsnag = \Bugsnag\Client::make();
        \Bugsnag\Handler::register($bugsnag);
    }

[kasperwandahl]

I'm experiencing the same issue. On my production site it only reports errors to bugsnag if APP_DEBUG is true, locally it works fine in all cases.

[kingsloi]

I think I found my issue, so I apologise @bugnsag!

In my local environment, I have LOG_CHANNEL=stack set in my .env, but my production env has LOG_CHANNEL=single, which I may have missed but I think it may have something to do with this commit, when they changed the default logging, and maybe Laravel Shift from 5.5 -> 5.6:

https://github.com/laravel/laravel/commit/ebb0a2a84fa431e30103c98cf4bed3fa3713ad59#diff-0c5eb58e57861e3bdcc3a2f6ae493626

It may not be that, but I've got a stinking feeling it is. My errors have been making it to Bugsnag on my production environment ever since I realised.

I hope that helps someone else!

[scofield-ua]

Experiencing the same issue on Laravel 5.7 (5.7.2). It works fine when APP_DEBUG=true though.

[daniel-de-wit]

Turns out my test errors didn't come in on a new project.. Due to event limit of Bugsnag subscription ( other project was spamming 200k+ logs a day on average).

If your seeing "Events Recently Sampled" in the main navigation bar. You will not receive new logs, click on it to find the culprit project.

[grund3g]

Oh WOW! You can't imagine how much time that took me. Would have been great if the Bugsnag support had pointed this out to me, as I have been in contact with them several times.

Closing this issue as it fixed the problem for me!

[murph133]

Fixed in production by setting LOG_CHANNEL=bugsnag in the .env file. LOG_CHANNEL=stack did not work.