-
-
Notifications
You must be signed in to change notification settings - Fork 7
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
rfc(decision): Escalating Forecasts Merged Issues #95
rfc(decision): Escalating Forecasts Merged Issues #95
Conversation
e3b3973
to
0a9cdc5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems well thought out to me 👍
Why should we not do this? What are the drawbacks of this RFC or a particular option if | ||
multiple options are presented. | ||
|
||
We need to determine how often events are getting merged and un-merged by users. A high volume could lead to high load to Snuba when we generate new Escalating Forecasts for the newly merged/un-merged Issues. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should have stats on this somewhere in datadog already. I don't think it'll be a huge issue to recalculate on merge, because even if we merge 1000 issues into a single issue, it's still just generating a single forecast.
I suppose that on unmerge is the larger risk, since we might trigger a large number of new forecasts from a single issue. Maybe the way to keep things safe here is to just keep the number of workers on the forecast queue low enough that it won't hurt snuba too much.
One other potential issue is that I think it takes a while for a merge to go through to clickhouse and to rewrite the group ids. So we'd need to delay the task, but I don't know that we have any specific confirmation on when the merge has completed (maybe sns can advise here)
Note by @onewland from discussion in Slack: |
lgtm |
TODO. Rendered RFC