Closed Bug 1431950 Opened 7 years ago Closed 7 years ago

Trees closed - failed jobs being retried as claim-expired


(Taskcluster :: General, enhancement)

Not set


(Not tracked)



(Reporter: philor, Assigned: bstack)



Starting sometime during yesterday's closure for bug 1431742 (no way for me to guess whether it's because of that, or just something broken while we were closed for that), in some but not all sorts of jobs failures are being retried as being claim-expired, rather than reporting the failure.

The two clearest examples I have are push-caused bustage in the Windows mingw build, and the wdspec test job, which shows it nicely because it has a crap-load of intermittent failures,
I closed inbound, autoland, central, beta, and release for this, since up to an 80% intermittent failure would be completely hidden from sheriff view by retrying until it turned green or failed six times in a row (and given how the mingw builds are showing, even permaorange wouldn't necessarily be clearly permaorange).
Looks like for tests, it affects all flavors of Linux, and Android 4.3 but not Android 6.0, and for builds, all browser builds on Linux (including Android and OS X cross-compiles and Windows mingw), but not spidermonkey builds on Linux. Dunno what set that implies.

Starting time must be "before early afternoon Pacific on 2018-01-19" since shows retries just after noon, but the next earlier push which would have shown it and didn't was at 03:56, which doesn't make a very narrow window.
Blocks: 1431742
Closed esr52 as well, since it turns out to have just enough tier-1 Linux taskcluster jobs to also be affected.
It appears that the worker is failing to report state due to a bug introduced to the workers yesterday

From the logs of i-0a201f1e0fb9be3fa [0] (papertrail link while it lasts [1]):

Jan 20 13:45:11 docker-worker: {"type":"task error","source":"top","provisionerId":"aws-provisioner-v1","workerId":"i-0a201f1e0fb9be3fa","workerGroup":"us-east-1","workerType":"gecko-3-b-linux","workerNodeType":"m4.4xlarge","taskId":"B8RyrbRKThewqMptCCR4Lg","message":"TypeError: Cannot read property 'purgeCaches' of undefined","stack":"TypeError: Cannot read property 'purgeCaches' of undefined\n    at Task.completeRun (/home/ubuntu/docker_worker/src/lib/task.js:592:58)\n    at Task.start (/home/ubuntu/docker_worker/src/lib/task.js:748:61)\n    at <anonymous>\n    at process._tickDomainCallback (internal/process/next_tick.js:228:7)","err":{}} 

It is likely that [2] was deployed for the first time during yesterday's outage. This will probably require us to fix the worker and roll out new ones. NI-ing :wcosta for help with that.

Flags: needinfo?(wcosta)
Assignee: nobody → bstack
I also note that we should always aim to set additionalProperties: false, whenever possible for example:

And a good way to avoid the issue we have now is to specify a default value:
  "default": {"purgeCaches": [], "retry": []}
In the JSON schema.. and then set useDefaults: true, when validating with ajv, that way we get the defaults injected.
Small stuff like that saves us a lot of bugs..
Commits pushed to master at
Bug 1431950 - check for onExistStatus before purgeCaches check
Merge pull request #361 from taskcluster/bug-1431950

Bug 1431950 - check for onExitStatus before purgeCaches check
We have landed the changes. However, gps has warned us of bug 1431742 comment 15. Given that, I have created a branch [0] that is the last known good commit before per-second billing changes (and also the commit that is being run in production now) and cherry-picked my changes on top of that. I will be creating an ami from that and deploying it shortly.
And [0] from my last comment was supposed to be
I saw the message this morning, I am working on making master branch stable again.
Flags: needinfo?(wcosta)
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.