Job details: Job start time is missing from running/pending jobs

RESOLVED FIXED

Status

P1
normal
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: emorley, Assigned: camd)

Tracking

Details

(Reporter)

Description

4 years ago
Migrated from:
https://github.com/mozilla/treeherder-ui/issues/79

Original summary:
Start time should not be displayed as the birth of the timestamp if not set #79 

lightsofapollo commented on 26 May:
> Showing: 12/31/69 4:00 PM is somewhat disturbing... I imagine the rea
> problem is the start time is not sent by buildbot pulse messages or is
> and not ingested (we are fixing same problem on TC end)
(Reporter)

Updated

4 years ago
Summary: treeherder-ui should not display a start time of "12/31/69 4:00 PM" if the timestamp was not set → treeherder-ui: don't display a start time of "12/31/69 4:00 PM" if the timestamp was not set
So tbpl displayed the correct timestamp, but tree herder does not until the job completes (in my experience)
I noticed this today, and I'm wondering if it's also responsible for the bogus completion statistics one sees when hovering over a build, e.g. "running, 14 minutes overdue, typically takes 30 minutes" (been running for about five minutes tops).
(Reporter)

Updated

4 years ago
Priority: P3 → P2
Summary: treeherder-ui: don't display a start time of "12/31/69 4:00 PM" if the timestamp was not set → Job start time is not set until the job completes
(Reporter)

Comment 3

4 years ago
iirc we talked about having the ability to distinguish between "job request time" and "job started time" (TBPL just uses the former), I can't remember whether that's something we included in the data model.
Summary: Job start time is not set until the job completes → Job start time is missing from running/pending jobs
(Reporter)

Updated

4 years ago
Summary: Job start time is missing from running/pending jobs → Job details: Job start time is missing from running/pending jobs
(Reporter)

Comment 4

4 years ago
Telling when a job started, even if it is still running/pending is pretty important for diagnosing issues when sheriffing (as well as trying to predict when a retrigger will complete, in order to tell how long before a repo can be reopened), so making this a P1.
Priority: P2 → P1
(Assignee)

Updated

4 years ago
Assignee: nobody → cdawson
Status: NEW → ASSIGNED
(Assignee)

Comment 5

4 years ago
The UI portion of this is fixed in: https://github.com/mozilla/treeherder-ui/commit/1870f37449fb0c48d7a94f39056eec1819658c8a

This cleans up the display of times in general as well.  If we don't have an end time, then we base duration off of ``now``.  If we don't have a start time, then we base the beginning of the duration off of the request time.  I also grouped all the times/duration together to make it more logically read-able.

However, there is a service portion as well.  Ends up we weren't persisting the start_timestamp value for running jobs at all!  Only for completed jobs.  That'll come in another commit.
(Assignee)

Comment 6

4 years ago
https://github.com/mozilla/treeherder-service/commit/b05c507b46c9965f8a953d67e7d82a7d0d2f036e

This commit fixes the service part, which ensures that we ingest the start_timestamp on running jobs.
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
(Reporter)

Updated

4 years ago
Blocks: 1060761

Comment 7

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

https://github.com/mozilla/treeherder/commit/040b8d22bfd616e0cbc79f1c87fd7d40cead5746
fix bug 1043320: ui portion for display of job detail times/durations
You need to log in before you can comment on or make changes to this bug.