rfc(decision): Escalating Forecasts Merged Issues #95
Conversation
NisanthanNanthakumar
force-pushed
the
rfc/escalatingforecastsmergedissues
branch
from
e3b3973
to
0a9cdc5
Compare
NisanthanNanthakumar
changed the title
| 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.
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