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

RESOLVED FIXED

Status

Tree Management
Treeherder
P2
normal
RESOLVED FIXED
3 years ago
2 years ago

People

(Reporter: emorley, Assigned: KWierso)

Tracking

Details

Attachments

(2 attachments)

(Reporter)

Description

3 years ago
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

3 years ago
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.
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.
Depends on: 1022701
(Reporter)

Comment 3

3 years ago
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.
(Reporter)

Comment 4

3 years ago
(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).
Yeah, we could start with a). b) would come for free if we implement point number 1 described in comment 2
(Assignee)

Comment 6

3 years ago
Created attachment 8486094 [details] [review]
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.
Attachment #8486094 - Flags: review?(cdawson)
Attachment #8486094 - Flags: feedback?(emorley)
(Assignee)

Comment 7

3 years ago
Created attachment 8486104 [details]
Screenshot
Attachment #8486104 - Flags: feedback?(emorley)
(Assignee)

Updated

3 years ago
Attachment #8486094 - Flags: feedback?(emorley)

Updated

3 years ago
Attachment #8486094 - Flags: review?(cdawson) → review+
(Assignee)

Comment 8

3 years ago
https://github.com/mozilla/treeherder-ui/commit/93cff5b002dc7bca43e591b371859184aa2d7e1e
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
(Assignee)

Comment 9

3 years ago
(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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Updated

3 years ago
Summary: New try pushes take a long time to appear on treeherder → Reduce the amount of time it takes for new pushes to appear in Treeherder.
(Reporter)

Updated

3 years ago
Attachment #8486104 - Flags: feedback?(emorley) → feedback+
(Reporter)

Updated

3 years ago
Depends on: 1065541
(Reporter)

Comment 10

3 years ago
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.
Assignee: nobody → kwierso
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago3 years ago
No longer depends on: 1022701
Resolution: --- → FIXED
Summary: Reduce the amount of time it takes for new pushes to appear in Treeherder. → Add a message if the specified revision does not exist (or has not been ingested yet)
(Reporter)

Updated

3 years ago
Blocks: 1080408

Comment 11

2 years ago
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.
You need to log in before you can comment on or make changes to this bug.