1240155 - If one of the bug suggestions is a duplicate, can we show the bug id of the bug it is a duplicate of?

Status: RESOLVED WONTFIX

(Tree Management :: Treeherder, defect)

Description

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

When I select a failed job and one of the bug suggestions for that failure is crossed out because it is resolved - duplicate, it would be nice to show what bug it is a duplicate of in the tooltip (instead of just "duplicate").

I believe that number is surfaced in the api as "dupe_of". If dupe_of is not null, it should be the id of the bug that this bug was duped to.

Comment 1

[Ed Morley [:emorley]]

I think Treeherder shouldn't try to fix up bad input data. The duped-to bug should be updated to have the correct summary / keyword moved over etc.

Comment 2

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

Sorry to poke this again, it would save a little extra effort in opening the bug and seeing what it was duped to. Often the dupe will have a different summary because it gathers in several related failures.

Comment 3

[Ed Morley [:emorley]]

Hi!

It seems that this feature request is trying to work around cases where a failure has been classified against the old (ie wrong) bug. That could happen if:
1. the bug to which they were duped isn't being suggested (ie: its summary/keywords needs updating)
2. the bugscache hasn't yet picked up the new bug (is updated every 15 minutes)
3. viewing a failure for which the summary is already generated and cached (summaries are not updated once generated, and then are cached for 24 hours; after that they will be regenerated/cached from fresh)
4. human error (ie the new bug is suggested, but for some reason they ignore it, click "show more" to view the closed bug, and choose that)

For (1) and (4) trying to work around this in Treeherder doesn't seem like the right place.
For (2), I suspect it affects this scenario very infrequently.
For (3), the proposed fix in this bug wouldn't help avoid the caching issue, unless the metadata was fetched client-side.

Is there something else I've overlooked? If not, then it feels like this should still be wontfix.

Comment 4

[Phil Ringnalda (:philor)]

You overlooked the fact that bug summaries are limited to 255 characters. (1) is only a complete solution if you have infinite space in the thing which replaces bug summaries in the fabled rewrite which will replace bugs as a source of suggestions. The summary for bug 1358898 would need to contain the filename of every test which is (on any platform, at any time, on any branch, after any rechunking) the last test to be run in a suite/chunk, while various assertion failure bugs would need to contain the filename of every single test which runs on debug. And even in those rare and wonderful cases where full-line searching actually works, a single match for the test filename causes us to not use full-line searching, so we'll get a suggestion of a three-month INCO timeout instead of an open full-line match, and then someone will file a new bug, and then it'll be duped, and then we'll get two suggestions, the INCO timeout and the duplicate.