can set maxEventsPerPage config option

[MaxBittker]

this needs to be noted in the docs but I don't want to have those pulled out before this ships.

I reset _sentErrors in _captureUrlChange and the pushState wrapper, which is a little bit janky but I believe it covers a wider range of applications without doing much harm. (although I could be misunderstanding the behavior of these apis)

[MaxBittker]

fixes
#679
#530
#435
in a naive way that could leave something to be desired. (time-based throttling and per-fingerprint throttling)

[Sija]

IMHO this implementation is too naive to be useful. Usually you'd want to throttle only one kind of an error, and not all of them regardless of their type.

[MaxBittker]

@Sija I don't necessarily disagree, might take another look at this tomorrow. interested in @benvinegar 's opinion here

[benvinegar]

@Sija – the problem is that determining what is the "same" error is non-trivial. We could probably make a "best guess" effort from the client, but there's a risk that it could fail on seemingly similar errors.

That being said, we're going to explore such a solution, see what it looks like, and revisit this.

[Sija]

@benvinegar I agree, good starting point could be simple heuristics based on filename, lineno, colno and function properties.

[benvinegar]

Now that #861 is enabled by default for everyone, I think we can come back to this. It's simple to implement, and there's an argument for having it in some situations (e.g. when pages are open in a tab for 24 hours straight).

One last ask: we should reset the captured error count whenever there's a URL change (e.g. via pushState).

[benvinegar]

Heard from a user yesterday for whom they could benefit from this.

[beck]

IMHO this implementation is too naive to be useful

This would stop the bleeding.

For my use-case, the platform is a site builder and sometimes raven-js picks up a user's 3rd party failures. I'm brought to this ticket because the latest event resulted in ~40k events, which hits the rate limit, stats look like the platform is down, and legitimate events are dropped.

This would allow us to set an upper-bound on the pathological scenarios.

[kamilogorek]

I don't see any particular reason why we'd not want to include this config option (with it being set to Infinite by default). What do you think about it now @benvinegar?

[benvinegar]

We should move forward; it keeps coming up.

I'd personally prefer if this were maxEventsPerPage or something (reset every page change, as I mentioned). Also, should not call this maxErrors but rather maxEvents since you can also send info or warning level events.

[kamilogorek]

@benvinegar updated the code, docs and TS definitions.

[benvinegar]

Biggest issue is that this will only work if breadcrumbs is enabled.

Unfortunately event/DOM instrumentation is tied really closely to breadcrumbs. We need to separate these two concepts.

Sorry! This ended up being tougher than I hinted at 😅

[benvinegar]

If breadcrumbs are disabled, this won't get called / won't reset.

[benvinegar]

Same comment as above.

[kamilogorek]

Ah, right. I didn't realise that.

Also we won't have location changes when we'll unify node/browser, which mean that we'd have to diverge an API once again in this case... I'm not sure about integrating that perPage in this case.
Making it a "total" number of events would be much easier and could be pulled to other SDKs as well easily.

[benvinegar]

Truly unifying these APIs is probably impossible. A common core is more realistic. We'll probably need to sit down and document what features are in both and see how we can get there.

Edit: I did think for a bit about how we could make this more generic, e.g. so we could use it server-side as well, but nothing comes to mind. maxEventsPerSession isn't right since a session can persist many pages. I mean, maxEventsPerPage could be used per Express-view.

[beck]

Using Sentry.io, the overage fees are priced per event, making this feature is essential. Especially if the consuming platform limits the ability to use whitelists, blacklists, and filters to cull all abusive scenarios.

[kamilogorek]

Linked this PR discussion to proper docs