New issue
Advanced search Search tips

Issue 911245 link

Starred by 1 user

Issue metadata

Status: Duplicate
Owner: ----
Closed: Dec 3
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug



Sign in to add a comment

Goma failing w/ "reached max number of active fail fallbacks" on the CQ

Project Member Reported by bpastene@chromium.org, Dec 3

Issue description

https://luci-milo.appspot.com/p/chromium/builders/luci.chromium.try/linux_chromium_rel_ng?limit=200

eg:
https://luci-milo.appspot.com/p/chromium/builders/luci.chromium.try/linux_chromium_rel_ng/246368
https://luci-milo.appspot.com/p/chromium/builders/luci.chromium.try/linux_chromium_rel_ng/246365
https://luci-milo.appspot.com/p/chromium/builders/luci.chromium.try/linux_chromium_rel_ng/246361
https://luci-milo.appspot.com/p/chromium/builders/luci.chromium.try/linux_chromium_rel_ng/246356

This is starting to happen pretty frequently. ie: for 10-30 minutes at a time every few days, many tryjobs in the middle of compiling crash due to the goma fallback error. (see also bug 908979) Instead of simply waiting it out for the backend to resolve itself, can we instead pursue a more permanent solution? Is there some quota we can indefinitely increase?
 
It looks like there was an increase in failure rate that seems to coincide with a BoringSSL roll: https://chrome-internal-review.googlesource.com/c/goma/client/+/723668
Never mind, Panopticon wasn't filling in the data before; it doesn't now look like any particular temporal correlation.
Mergedinto: 899828
Status: Duplicate (was: Untriaged)

Sign in to add a comment