From 86c46e46b3386a258ed2dd51dcd2b4e932d4097e Mon Sep 17 00:00:00 2001 From: Dmitry Vyukov Date: Thu, 1 Sep 2022 11:28:48 +0200 Subject: dashboard/app: fix a reporting race When dashboard receives first crash for a new bug, it first creates the Bug object and then separately creates the first Crash and updates Bug accordingly. Currently it's possible that reporting kicks in right in between and sees the Bug without any crashes. This may cause the bug to be mis-classified by the filter. Wait for the first crash before reporting bugs. No easy way to test this since this requires a race condition. But not breaking any of the existing tests should be good enough. --- dashboard/app/reporting.go | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'dashboard') diff --git a/dashboard/app/reporting.go b/dashboard/app/reporting.go index cc4fa2e22..641af4e51 100644 --- a/dashboard/app/reporting.go +++ b/dashboard/app/reporting.go @@ -336,6 +336,13 @@ func createNotification(c context.Context, typ dashapi.BugNotif, public bool, te } func currentReporting(c context.Context, bug *Bug) (*Reporting, *BugReporting, int, string, error) { + if bug.NumCrashes == 0 { + // This is possible during the short window when we already created a bug, + // but did not attach the first crash to it yet. We need to avoid reporting this bug yet + // and wait for the crash. Otherwise reporting filter may mis-classify it as e.g. + // not having a report or something else. + return nil, nil, 0, "no crashes yet", nil + } for i := range bug.Reporting { bugReporting := &bug.Reporting[i] if !bugReporting.Closed.IsZero() { -- cgit mrf-deployment