sentry-php: Events are sent only on shutdown: does not work in combination with async or long running processes like queue workers

For Laravel, the approach I’m currently testing is to apply within ExceptionHandler:

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

            if (app()->runningInConsole()) {
                app('sentry')->getClient()->getIntegration(\Sentry\Laravel\Integration::class)->flushEvents();
            }
        }

        parent::report($exception);
    }

I implemented a workaround which might be interesting: I created a HttpClient plugin which waits for each promise and swaps it with a FulfilledPromise. I am not 100% satisfied because, in a long running process, I am still bloating the memory with useless data, but I found it easier than trying to use my own client or my own transport (every class is final otherwise it would have been way easier). The code is, more or less:

use Exception;
use Http\Client\Common\Plugin;
use Http\Promise\FulfilledPromise;
use Http\Promise\Promise;
use Psr\Http\Message\RequestInterface;

class SynchronizeHttpClientPlugin implements Plugin
{
    public function handleRequest(RequestInterface $request, callable $next, callable $first): Promise
    {
        /** @var Promise $promise */
        $promise = $next($request);

        try {
            $promise->wait();
        } catch (Exception $e) {
            // do nothing...
        }

        // we return an already fulfilled promise so that the sentry client is happy
        return new FulfilledPromise(null);
    }
}

And, instead of initializig sentry with the usual Sentry::init():

$options = []; // my options here...
$client = ClientBuilder::create($options)
        ->addHttpClientPlugin(new SynchronizeHttpClientPlugin())
        ->getClient();

Hub::setCurrent(new Hub($client));

I hope it’s useful for somebody!

Thanks for the report, we are aware that this is a big problem due to us incorrectly implementing the asynchronous sending of the events and I’m working on a fix which has a high priority on my to-do list. Since this is going to require a lot of changes in the API I didn’t find the time yet to open the PR, but on my forked repository there is a branch with the WIP changes that should solve the issue and allow the correct integration of the SDK with ReactPHP and similar libraries. I really hope to be able to submit a PR soon for review

@B-Galati this is the issue, I’ll change the title to make it more clear. As for the proposed solutions, these are the pending PRs: #799 & #813

Closing this issue as it has been solved in the referenced PR. I’m sorry this has been a so long outstanding issue, we will release the new version asap

Issue is still top-priority for 2.2 and in the next days I’m gonna hopefully update my PR with the changes that will fix the issue on time for all, but due to the vacation period I don’t know when it will be merged. The release plan in my head is to merge all pending PRs for that version along with this fix and then release the new version

@palicao that’s actually way better than my current work around 👍

I think it’s ok to break BC if it’s broken anyway.

I’m having a déjà vu on this discussion 😄 Breaking BC is a no-go, we are striving to follow semver and we will continue doing it.

IMHO, it would be cool if you could open issues on GitHub for those you know but have not been opened publicly.

I’m not sure I get what you mean here. The proposals about how to solve this specific issue are two public PRs

The transport and the client have to be hold on to, or otherwise they would have to be constructed each time.

We’re aware of this since it lead to a similar issue in Laravel queue workers, see getsentry/sentry-laravel#228. We’re trying an approach in #799, and in general a simple flush() should suffice as a way to send events when needed.