1317540 - Backfill can schedule jobs in the future

Status: RESOLVED FIXED

(Tree Management :: Treeherder, defect)

Description

[Armen [:armenzg]]

wlach: is there a better way to determine the revision a job id/guid is associated to? I tried the jobs endpoint w/o success.
I think this could be a regression of https://github.com/mozilla/treeherder/commit/8ccc91ee9524b207414b962146e8dead03cb0b72

For some reason, I think the client is trying to access this:
https://treeherder.mozilla.org/api/project/mozilla-inbound/resultset/?id=144594
instead of this:
https://treeherder.mozilla.org/api/project/mozilla-inbound/resultset/144594/

This bug is important to fix as it can make the lives of sherrifs and jmaher rather confusing and it wastes resources.

When someone requests a backfill from treeherder on a push they actually get the action executed on an incorrect push.
I don't know if the code to calculate the revision from the Pulse message has always been wrong OR if the Pulse message started sending different data.

Given this url [1] and this screenshot to confirm it [2].
We can clearly see that we've selected job 39173862 on revision e12e761d2106b1c5ea836462177617e147176ee5.

Now, I go ahead and request a backfil on that job.
Few minutes later I will find a 'Sch' job on the topmost revision (be95aa5249cf8d1cf33434273f7c789e332b886d) rather than on the revision I requested (e12e761d2106b1c5ea836462177617e147176ee5).

If we open the log of the Sch job [3], it is clear that the URL I construct is incorrect as it has the topmost revision instead of the one I requested.

The way I calculate the revision is the following [4]:
> job_id = data['job_id']
> job_info = treeherder_client.get_jobs(repo_name, id=job_id)[0]
> result_sets = treeherder_client.get_resultsets(repo_name, id=job_info["result_set_id"])
> revision = result_sets[0]["revision"]

To reproduce locally here's the code:
treeherder_client = TreeherderClient()
job_info = treeherder_client.get_jobs('mozilla-inbound', id='39173862')[0]
result_sets = treeherder_client.get_resultsets('mozilla-inbound', id=job_info['result_set_id'])
print result_sets[0]["revision"]

It seems the bug has been there since July of last year:
https://github.com/mozilla/pulse_actions/commit/601758f3d6ab8f97fd48348f5ef9e91f22fc5073#diff-24fdc489c2cf77cd8461dbaa0d51d265R27
> revision = treeherder_client.get_resultsets(repo_name, id=resultset_id)[0]["revision"]

I believe the assumption of the original code is that I would get *only* information about one resul set, however, I get 10 (which the documentation says is the default).

[1] https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&filter-searchStr=talos%20osx%20g2%20e10s&fromchange=31b6c03c69f18df000420d218b7b233f739af584&selectedJob=39173862
[2] http://people.mozilla.org/~armenzg/sattap/7b6644a7.png
[3] https://tc-gp-public-31d.s3-us-west-2.amazonaws.com/ateam/pulse-action-dev/b7f14cbf-8737-439c-9325-f6222122f3d6
treeherder_job_action Request for https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=be95aa5249cf8d1cf33434273f7c789e332b886d&selectedJob=39173862
[4] https://github.com/mozilla/pulse_actions/blob/master/pulse_actions/handlers/treeherder_job_action.py#L119

Comment 1

[Joel Maher ( :jmaher ) (UTC -8)]

questions for wlach in comment 0

Comment 2

[William Lachance (:wlach)]

I think bug 1311185 broke filtering on result sets by id. Sorry about that. :( I'll fix now.

Comment 3

[GitHub Autolander Bot]

Attachment: [treeherder] wlach:1317540 > mozilla:master

Comment 4

[William Lachance (:wlach)]

Comment on attachment 8810874 [details] [review]
[treeherder] wlach:1317540 > mozilla:master

Our unit tests really had some holes in them. :(

Comment 5

[Treeherder GitHub Bugbot]

Commit pushed to master at https://github.com/mozilla/treeherder

https://github.com/mozilla/treeherder/commit/e70784858de112bb8e637dfa90c57a14df265f26
Bug 1317540 - Add back various options for filtering result sets by id (#1981)

Comment 6

[William Lachance (:wlach)]

Will deploy to master later today.