Perf: Fall back to reporting if bisection fails

Recently, a change (b134f59) was introduced to fail the bisect workflow if Chromeperf fails to create a job, which prevents confusing "success" statuses when no job was actually created. However, this also inadvertently stopped bugs from being filed because the workflow failed completely instead of falling back to reporting. This change catches the bisection failure and falls back to processAnomaliesAsReporting so that users are still notified of regressions.

Bug: b/502224585

goalie(skia/fix-bug-502224585)

Change-Id: I20d5d17558775d9eb202a5aebc0549fcf4eac788
Reviewed-on: https://skia-review.googlesource.com/c/buildbot/+/1209869
Reviewed-by: Maxim Sheshukov <[email protected]>
Commit-Queue: Tony Seaward <[email protected]>

Author: SeawardT

perf/go/workflows/internal/maybe_trigger_bisection.go

@@ -74,11 +74,14 @@ func MaybeTriggerBisectionWorkflow(
 			return nil, skerr.Wrap(err)
 		}
 		if bisectionAllowed {
-			return processAnomaliesAsBisection(ctx, input)
-		} else {
-			// Fallback to reporting if the rate limiter prevents creating bisect jobs.
-			return processAnomaliesAsReporting(ctx, input)
+			res, err := processAnomaliesAsBisection(ctx, input)
+			if err == nil {
+				return res, nil
+			}
+			workflow.GetLogger(ctx).Error("Bisection failed, falling back to reporting.", "error", err)
 		}
+		// Fallback: bisection not allowed or failed.
+		return processAnomaliesAsReporting(ctx, input)
 	case ag_pb.GroupActionType_REPORT:
 		return processAnomaliesAsReporting(ctx, input)
 	case ag_pb.GroupActionType_NOACTION: