Closed Bug 1174273 Opened 10 years ago Closed 9 years ago

UI displays two rows for the same revision

Categories

(Tree Management :: Treeherder: Data Ingestion, defect, P1)

Product:
Tree Management
Component:
Treeherder: Data Ingestion
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1126896

People

(Reporter: armenzg, Unassigned)

References

Details

In production I see 42bf8560b395 [1] In stage I see 0628a6c3be52 and 42bf8560b395 [2] This seems pretty bad. [1] https://treeherder.mozilla.org/#/jobs?repo=ash [2] https://treeherder.allizom.org/#/jobs?repo=ash
Component: Treeherder → Treeherder: Data Ingestion
Priority: -- → P1
It's interesting the only thing which appears shared between those two pushes on allizom are the push date/time in the ui? The underlying revisions appear different. Jgriffin mentioned he's going to have a look at hg.
This is quite weird. On stage, Treeherder created an extra push where there wasn't one; push 0628a6c3be52 actually is part of 42bf8560b395. Production did the right thing. On stage, the actual jobs were split up (seemingly at random) between the two pushes. For example, the job at https://treeherder.allizom.org/logviewer.html#?job_id=25006&repo=ash is reported as belonging to (the phantom) push 0628a6c3be52, but all the log details show the right push 42bf8560b395. No idea what happened here; is there any way to see why the extra push was created on stage?
I'll look into this.
Assignee: nobody → emorley
Same happened today again for the pushes of the mozilla-central to mozilla-aurora merge: https://treeherder.mozilla.org/#/jobs?repo=mozilla-aurora&revision=7f2f0fb041b1
I wonder if this could be the way we generate a revision_hash. If we just used the tip revision, we could likely avoid this issue. Or be sure to check for dup revision hashes better? Anyway, a place to start looking. :)
I'm not going to have time to look at this until after deliverables; someone else feel free to take a look in the meantime :-)
Assignee: emorley → nobody
Updating summary to better find this bug. Also this is not only on allizom anymore but also production.
Summary: Seeing two rows on allizom for only one push → UI displays two rows for the same revision
Continuing to see this. Perhaps it's related to pushing big merges, where the are long lists of revisions in each push ?
Seems to be, yes. As it looks like we haven't seen it since the last merge. As of yesterday it is there again: https://treeherder.mozilla.org/#/jobs?repo=mozilla-aurora&revision=e2031358e2a6
This was actually a dup. And we haven't seen this since March 2016. fixed by commit https://github.com/mozilla/treeherder/commit/2a9dbefa49d26d8d0ddc7c402c571691b1679770
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.