-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[General Inquiry]: Should errors be limited by 'sessionEventLimit'? #480
Comments
The design was to limit cost to customers, but I agree that it's inconvenient. Here is what I propose. Do you have any feedback? const config: AwsRumConfig = {
...
sessionEventLimitOverride: [
// list of RUM event types
['js-error', 0] // where zero removes the limit
['other-event', 5] // count against override limit before counting against overall sessionEventLimit
]
} |
Yeah ok, that makes sense. Just thinking about it, it would be a huge win for us to be able to limit all of the individual event types, just as you have there. So that looks pretty much perfect to me. |
Perfect, I'll see what I can do. Out of curiosity, which other events were you thinking about using this configuration for? |
I would probably do something like this once this configuration is available. const config: AwsRumConfig = {
...
sessionEventLimitOverride: [
['js-error', 0],
['fetch', 0], // Assuming this is correct to capture all HTTP
['pageview', 20], // Allow viewing some of the user journey
// Maybe other limits for performance events
]
} |
There are several requirements for this to be closed out
|
What is your general inquiry?
I wasn't expecting the behaviour of errors not being recorded when a sessionEventLimit is not, got a bit caught out by it. Is there a reason for blanket preventing all events based on the limit, including errors?
Would be handy if this was configurable. Being able to still collect errors beyond when you may care about other events in the session.
The text was updated successfully, but these errors were encountered: