Skip to content
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

Throttle errors on the Foundation site #91

Closed
seanlip opened this issue Oct 27, 2018 · 4 comments
Closed

Throttle errors on the Foundation site #91

seanlip opened this issue Oct 27, 2018 · 4 comments
Assignees

Comments

@seanlip
Copy link
Member

seanlip commented Oct 27, 2018

Per discussion with @hoangviet1993, let's throttle errors, similar to oppia/oppia#5767

@hoangviet1993
Copy link
Contributor

hoangviet1993 commented Oct 27, 2018

@seanlip

I am trying to brainstorm different approaches to this problem of error spamming.
This SO answer raises an interesting solution
https://stackoverflow.com/questions/26271024/what-is-a-good-backoff-algorithm-for-throttling-logging-of-errors

Another way would be to enqueue the log somewhere in memory and de-duplicate on a timer. For example, every ten seconds you could count the number of occurrences of each message and log them all

Instead of putting exceptionHandler on a 5 second cool-down, here is a simplified algorithm

  1. Store these stack-traces on localStorage
  2. Count the number of occurrences and de-duplicate them (this might be complicated?!)
  3. Similar to the changes in your PR, if 10 seconds have occurred since the last exception logged, send the compiled list of different errors and the number of its occurrences.

I know all of these stuff sounds like over-engineering for a simple problem of preventing spam from error logging. I would like to try to be exhaustive in solving this problem so pardon my over-thinking!

@seanlip
Copy link
Member Author

seanlip commented Oct 27, 2018

No problem! Analysis is good :)

However, I think we don't need a complex solution to this problem, and the existing simple-minded one will do. I would go with whatever has the simplest code for now, unless there's a compelling reason to do otherwise.

@hoangviet1993
Copy link
Contributor

That is fair! I will be mirroring your changes in my PR then. Thanks!

@hoangviet1993
Copy link
Contributor

Issue fixed by PR #92. Closing this issue!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants