Concurrent flush calls never ends (does not reject/return/throw)

[enapupe]

Package + Version

• @sentry/core

Version:

v5.0.8

Description

Flush never resolves/rejects (hangs forever) when called concurrently.
When called concurrently, the second (or is it the first?) flush call never resolves. It seems the second call to flush kills the setInterval happening for the first on:

sentry-javascript/packages/core/src/baseclient.ts

Line 215 in e1fe74c

clearInterval(this._processingInterval);

(clearing the interval here ^^^^ kills other possibly running calls, it should resolve all instances instead.)

In other words, it seems _isClientProcessing relies on setInterval in order to resolve/reject the promise, but this interval is being cleared on the referenced line above. This makes _isClientProcessing promise to HANG forever.

One easy (but kinda ugly) workaround, would be adding a Promise.race using that timeout - I've tested this change locally and it works OK:

    /** Waits for the client to be done with processing. */
    _isClientProcessing(timeout) {
        return Promise.race([new Promise(resolve => {
            let ticked = 0;
            const tick = 1;
            if (this._processingInterval) {
                clearInterval(this._processingInterval);
            }
            this._processingInterval = setInterval(() => {
                if (!this._processing) {
                    resolve(true);
                }
                else {
                    ticked += tick;
                    if (timeout && ticked >= timeout) {
                        resolve(false);
                    }
                }
            }, tick);
        }), new Promise((resolve) => {
            setTimeout(() => {
                if (!this._processing){
                    return resolve(true)
                }
                return resolve (false)
            }, timeout)
        })])

[esetnik]

@enapupe one major downside of the Promise.race solution is that the concurrent flush will take a minimum of 2s to complete. This is not the case for a real flush with a small or empty queue so it's artificially slowing down the speed of concurrent flush operations.

[enapupe]

Absolutely, this is just a hack to illustrate what's going on, having it default to that timeout would be really bad.

[kamilogorek]

Thanks for the detailed repro @enapupe! Fixed in #2143