Implement client-side rate limiting / avoid sending the same error repeatedly

[benvinegar]

No description provided.

[claygriffiths]

I believe this was implemented in #92, but it is definitely not filtering out repeat errors.

For instance, if you have an exception being thrown on a browser event such as mouse drag then you can be in a world of hurt.

[mattrobenolt]

@claygriffiths #92 just added a callback so you could implement your own rate limiting or any filtering that you want.

But we should get something primitive in core just to prevent something as you pointed out from breaking the world.

[claygriffiths]

Aha! Sorry for not looking into that more.

If anyone is looking for a solution this what I'm using to filter out exceptions. It is absolutely by no means perfect but it will work in the meantime.

var RavenLimiter = {};

Raven.config('#####', {
    shouldSendCallback: function(data) {

        if ( data.message in RavenLimiter ) {
            return false;
        }

        RavenLimiter[data.message] = true;

        setTimeout(function() {
            delete RavenLimiter[data.message];
        }, 5000);

        return true;

    }
}).install();

[frewsxcv]

A function I would find helpful would be something like captureMessageOnce such that it only sends the message to Sentry once, and won't send it again.

[slorber]

+1 for this

My usecase:

• A SPA build with React
• Only the first errors are often meaningful
• After first errors, React may issue a lot of errors repeteadly that are useless for debugging: I'd like to filter those

[benvinegar]

Per the title, I think #861 solves the crux of the title / conversation in this issue. Closing.

[slorber]

Not sure it will do the job for my usecase @benvinegar because you only compare current error with last error. Sometimes we have n errors that repeat themselves but they are not necessarily consecutive, it's the case often when using React: once it's in a bad state errors can be thrown from everywhere and are not necessarily always the same.

Maybe it would be better to keep a little history of last errors, and to use it in combination with a rate-limiting system like one proposed by @oliviertassinari #530 (comment)

[carestad]

Any way to implement this in a more recent version of Sentry?

[vnglst]

I don't think the new client of Sentry supports client side throttling.,

I've adapted the example above to adds it (we were having issues with errors flooding Sentry, >1.000.000 in couple of hours from just a few clients):

    const eventLimiter = {};


    SentryClient.init({
        // ...
        beforeSend: (event, hint) => {
            const msg = hint?.originalException?.message;

            // do not send event if already sent in last 1 minute
            if (msg && msg in eventLimiter) {
                console.log("Rate limiting activated for", msg);
                return null;
            }

            eventLimiter[msg] = true;

            setTimeout(() => {
                delete eventLimiter[msg];
            }, 1 * 60 * 10000);

            return event;
        }
});