Просмотр исходного кода

fix(attachments): Faster counts for issues with many crash reports (#27913)

The number of crash reports to store per issue group can be bounded. If such a
limit is in effect, Sentry needs to count the existing crash reports. There can
be issues with a large number of crash reports from before a limit has been
enforced, in which case that count query took a long time.

In fact, we do not care about the actual count, just whether it exceeds the
currently allowed maximum. Therefore, constrain the query.
Jan Michael Auer 3 лет назад
Родитель
Сommit
c42a756596
1 измененных файлов с 4 добавлено и 3 удалено
  1. 4 3
      src/sentry/event_manager.py

+ 4 - 3
src/sentry/event_manager.py

@@ -160,9 +160,10 @@ def get_stored_crashreports(cache_key, event, max_crashreports):
         return cached_reports
         return cached_reports
 
 
     # Fall-through if max_crashreports was bumped to get a more accurate number.
     # Fall-through if max_crashreports was bumped to get a more accurate number.
-    return EventAttachment.objects.filter(
-        group_id=event.group_id, type__in=CRASH_REPORT_TYPES
-    ).count()
+    # We don't need the actual number, but just whether it's more or equal to
+    # the currently allowed maximum.
+    query = EventAttachment.objects.filter(group_id=event.group_id, type__in=CRASH_REPORT_TYPES)
+    return query[:max_crashreports].count()
 
 
 
 
 class HashDiscarded(Exception):
 class HashDiscarded(Exception):