1048043 - Add a message if the specified revision does not exist (or has not been ingested yet)

Status: RESOLVED FIXED

(Tree Management :: Treeherder, defect, P2)

Description

[Ed Morley [:emorley]]

After pushing to try, within 10-20 seconds, the new push is visible on hgweb pushlog and thus TBPL.

However it took 5-6 mins for it to appear on https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=349e5eb93687

Comment 1

[Jim Mathies [:jimm]]

This may seem trivial, but when you're pushing to try and you need to post a link to a bug, this can be a real pita.

Comment 2

[Mauro Doglio [:mdoglio]]

There's a combination of issues here:
- treeherder doesn't display new result set unless there is at least a new job attached to it.
- treeherder sometimes takes a couple of minutes to be aware of new result sets.
Given that new jobs are fetched from buildapi once a minute and are discarded if the result set they belong to hasn't been loaded yet we could have a situation where the time to display a new resultset could take a few minutes as reported by :edmorley 

I think the best way to mitigate this issue is to
1) Show empty result sets in the ui as soon as they are available. This can be done broadcasting a socket.io event very much like we do for new jobs
2)change the way treeherder ingests new result sets. At the moment this is done polling hg.m.o every minute for changes. We could use a pulse consumer to get the updates and eventually fetch the push details with a quick request to https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?full=1&rev=e8425ac082d7.

AFAIK 2) depends on Bug 1022701, but we can start implementing 1) separately.

Comment 3

[Ed Morley [:emorley]]

Thank you for looking at this :-)

I think there's also:

3) Make sure that if someone clicks a try link (eg the one output from the hg.mozilla.org response after pushing to try), the resultant page:
  a) Displays a useful message "Unknown push"
  b) Refreshes automatically when the backend ingests that push, so the user doesn't have to refresh the page.

Comment 4

[Ed Morley [:emorley]]

(In reply to Ed Morley [:edmorley] from comment #3)
>   a) Displays a useful message "Unknown push"

To be clearer:

a) Displays a useful message (eg "Unknown push") if the backend hasn't yet ingested it (ie in the 60s between polls, or if the hg pushlog is erroring out temporarily a la bug 1040308).

Comment 5

[Mauro Doglio [:mdoglio]]

Yeah, we could start with a). b) would come for free if we implement point number 1 described in comment 2

Comment 6

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

Attachment: Link to pull request 155

This adds a brief message informing the user that Treeherder currently doesn't know about the specified revision, whether that's because the revision doesn't actually exist or because that push just hasn't been processed yet.

I've tested it locally with a try push, and the message will appear for a minute or so before eventually being replaced with the actual push information once Treeherder processed the push.

Comment 7

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

Attachment: Screenshot

Comment 8

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

https://github.com/mozilla/treeherder-ui/commit/93cff5b002dc7bca43e591b371859184aa2d7e1e

Comment 9

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

(In reply to Ed Morley (At work week 6th-13th Sept) [:edmorley] from comment #3)
> Thank you for looking at this :-)
> 
> I think there's also:
> 
> 3) Make sure that if someone clicks a try link (eg the one output from the
> hg.mozilla.org response after pushing to try), the resultant page:
>   a) Displays a useful message "Unknown push"
>   b) Refreshes automatically when the backend ingests that push, so the user
> doesn't have to refresh the page.

Well, part A is done, and from my testing, part B already happens.

Reopening so that we can reduce the amount of time it takes for Treeherder to process incoming pushes by either polling for changes more frequently or having a push hook that manually signals Treeherder to process a new push.

Comment 10

[Ed Morley [:emorley]]

To keep things easier to track, I've broken the remaining issues out of this bug:
* Bug 1065568 - Make the pushlog ingestion cron more frequent
* Bug 1065576 - Result sets containing no jobs only appear in the UI after a page reload
* Bug 1065567 - Use pulse for quicker pushlog ingestion rather than polling json-pushes

Tweaking summary for this bug to reflect the part that was done here - bug 1065541 tracks the further tweaks needed to the patch.

Comment 11

[Treeherder GitHub Bugbot]

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

https://github.com/mozilla/treeherder/commit/d6228d3f966c4e239205fe9c3fd5066f57b92440
Bug 1048043 - Add a message for when a revision ID cannot be found.

https://github.com/mozilla/treeherder/commit/c652d5603100b78369186ad64a7686d05be633b7
Merge pull request #155 from KWierso/1048043

Bug 1048043 - Add message for when revision not found.