1193115 - Backfilling after decision tasks haven't been run for a while does weird things

Status: RESOLVED INVALID

(Taskcluster :: Services, defect)

Description

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

So, bug 1193098 meant that the gecko-decision tasks weren't being scheduled for most of the afternoon. Once the version-control-tools commit that caused those failures was backed out, it looked like the decision tasks were being backfilled.

But if I look at the trees, it looks like all of the decision tasks ended up being run on a single revision (per tree), causing lots of TC build jobs to be started on that one revision: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=bc66277dd583

If you look at https://treeherder.mozilla.org/#/jobs?repo=fx-team&fromchange=e7d7cc7dbd04&filter-searchStr=decision&tochange=3536377b0dcb you'll see that revision 15aa37df726c got 10 decision tasks, and there are 10 pushes from 3536377b0dcb to 15aa37df726c 


I'm not really sure what this bug should be about. I guess it could either
a) backfill properly, so each push gets a single decision task scheduled
or
b) not do what it did today, since we don't need ten sets of builds and tests on a single revision (when the breaking issue was fixed, don't attempt a backfill, just let things go forward from there?)

Comment 1

[Selena Deckelmann :selenamarie :selena]

We think this is a problem with mozilla-taskcluster, and somehow pushlog backlog getting aggregated into one decision task and posting it on only the most recent push. 

More investigation needed.

Comment 2

[Jonas Finnemann Jensen (:jonasfj)]

bstack argues this was refactored when backfill moved in-tree with actions.json