Sentry-laravel: Handle error asynchronously

[mehrdad-shokri]

I noticed adding

if ($this->shouldReport($exception)) {
     app('sentry')->captureException($exception);
}

causes response time to jump from 500ms to 2000ms.
What is recommended way to handle error reporting asynchronously?
Maybe firing an event?

[stayallive]

While it's possible it generaly not recommended sending events async since those events might not even come through then. The PHP SDK has an experimental async option, but it doesnt properly handle all errors at the moment (so its not enabled by default).

You can enable it by adding 'curl_method' => 'async', to the sentry.php config file in your application.

But again, it's probably better to have it stay on the default and take the performance panelty and focus on fixing the errors instead of possibly missing some and not noticing bugs because of it 😄

[zeshan77]

Hi @stayallive 'curl_method' => 'async' still does not send reports to sentry in queue.

Not sure if I'm missing something?

My config sentry.php is given below

return array(
    'dsn' => env('SENTRY_DSN'),

    // capture release as git sha
    // 'release' => trim(exec('git log --pretty="%h" -n1 HEAD')),

    // Capture bindings on SQL queries
    'breadcrumbs.sql_bindings' => true,

    // Capture default user context
    'user_context' => true,

    'curl_method' => 'async'
);

Handler->report() method:

public function report(Exception $e)
    {
        if (app()->bound('sentry') && $this->shouldReport($e))
        {
            app('sentry')->captureException($e);
        }

        parent::report($e);
    }

[stayallive]

@zeshan77 no they are still not sent through the Laravel queue (we do not support that in any way), but now there should be an shell_exec call to curl which sends the request to Sentry in the background. So the requests should not add an significant extra time dispatching the request, but it’s not sent through the queue.

[stayallive]

Closing this because lack of response and the issue should be resolved using the config options.

[royduin]

Maybe document the curl_method config option somewhere? In my opinion it should be default set to async. What if Sentry is down? We've to wait for a timeout until the page loads?

[stayallive]

@royduin as mentioned before: "The PHP SDK has an experimental async option, but it doesnt properly handle all errors at the moment (so its not enabled by default).". This is also why it's not documented AFAIK. The timeout is set to 2 seconds by default, so it's not a 30 second wait if Sentry would be unreachable.

In the 2.0 version of the SDK work is being made to make the method of sending pluggable so everyone can decide and implement how the event is being sent (async/sync/etc.) as they see fit. This will also be documented so that might help out.

[Spriz]

It's documented now with the 3 options sync, async and exec - does that mean using exec would be considered "safe to use"? :)

[stayallive]

@Spriz I am not sure, I would say the exec is "less" safe since that executes a command line curl command (which has te be available on the server/container the application is running on). The async is just using the PHP curl functionality to dispatch which might still block the request if the request is still running when your own code is ready.

So the exec is probably much less intrusive but might depends on your environment if it works correctly.

[Spriz]

Roger 💪 But as long as we make sure CLI curl works, the exec is "safe" 👍 ?

[stayallive]

Looking at getsentry/sentry-php#132 there could be issues with lingering processes when using a React event loop, and there is an issue that indicates there might be memory issues (getsentry/sentry-php#284, although this one should be solved by limiting the data that can be sent).

So yes it should be safe but I have no real world example where it's being used.