log summary shown on different jobs (caching issue?)

RESOLVED FIXED

Status

P1
normal
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: aryx, Assigned: wlach)

Tracking

Details

Attachments

(1 attachment)

Saw this the second time this week but never before.

Backed https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=9055ad92499a476abbd5205d0918791c628b1252 out as https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=b50520db14601df2cc29d23f211000a309b62026

Then checked the wpt errors for https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=d64b1dfabdeffd62175313a1cd0734e25c30fee9

Actual result: Normal log loading animation, but one of the compile failures for the backed out changes (both the changes and the backout landed later) shown.

Updated

2 years ago
Blocks: 1281820
Component: Treeherder → Treeherder: Data Ingestion
Flags: needinfo?(wlachance)
Priority: -- → P1
Among the things this could be about are the steps:

1. Click on a job which will load results very slowly
2. Before those results load, click or N your way to some other job

Expected: see the summary for "some other job"

Actual: see the summary for the slow loading job when it finally loads over the top of the job that's actually selected

Which is either a very long-standing bug being hit more often due to bug 1281820 exposing it by making jobs with lots of failures very slow to load failure summaries, or perhaps a regression if that long-standing bug was actually fixed at some point.
I think there's a race somewhere in the UI. Looking into it. I'm also going to investigate the slowness of loading the failure summary.
Assignee: nobody → wlachance
Flags: needinfo?(wlachance)
Bug 1134698, so the race isn't a regression. If you need failures that will be slow to load, https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1304930&tree=all is generally a pretty good source.
See also bug 1311454, e.g.

19:33:20.962 Error: data.bugs is undefined
bugSuggestionOptions@https://treeherder.mozilla.org/js/index.min-da463c4eb025aef55e275ccc8f3b51a0.js:29:19730
buildUIData@https://treeherder.mozilla.org/js/index.min-da463c4eb025aef55e275ccc8f3b51a0.js:29:20321
ThUnstructuredLine@https://treeherder.mozilla.org/js/index.min-da463c4eb025aef55e275ccc8f3b51a0.js:29:21564
mergeLines/lines<@https://treeherder.mozilla.org/js/index.min-da463c4eb025aef55e275ccc8f3b51a0.js:29:24455
Gn@https://treeherder.mozilla.org/js/index.min-da463c4eb025aef55e275ccc8f3b51a0.js:22:5144
ue@https://treeherder.mozilla.org/js/index.min-da463c4eb025aef55e275ccc8f3b51a0.js:22:22935
mergeLines@https://treeherder.mozilla.org/js/index.min-da463c4eb025aef55e275ccc8f3b51a0.js:29:24140
buildFailureLineOptions@https://treeherder.mozilla.org/js/index.min-da463c4eb025aef55e275ccc8f3b51a0.js:29:24750
thTabs.tabs.autoClassification.update/</<@https://treeherder.mozilla.org/js/index.min-da463c4eb025aef55e275ccc8f3b51a0.js:29:23753
processQueue@https://treeherder.mozilla.org/js/index.min-da463c4eb025aef55e275ccc8f3b51a0.js:9:5468
scheduleProcessQueue/<@https://treeherder.mozilla.org/js/index.min-da463c4eb025aef55e275ccc8f3b51a0.js:9:5735
$RootScopeProvider/this.$get</Scope.prototype.$eval@https://treeherder.mozilla.org/js/index.min-da463c4eb025aef55e275ccc8f3b51a0.js:9:19126
$RootScopeProvider/this.$get</Scope.prototype.$digest@https://treeherder.mozilla.org/js/index.min-da463c4eb025aef55e275ccc8f3b51a0.js:9:16811
$RootScopeProvider/this.$get</Scope.prototype.$apply@https://treeherder.mozilla.org/js/index.min-da463c4eb025aef55e275ccc8f3b51a0.js:9:19553
scheduleApplyAsync/applyAsyncId<@https://treeherder.mozilla.org/js/index.min-da463c4eb025aef55e275ccc8f3b51a0.js:9:12215
completeOutstandingRequest@https://treeherder.mozilla.org/js/index.min-da463c4eb025aef55e275ccc8f3b51a0.js:6:7213
Browser/self.defer/timeoutId<@https://treeherder.mozilla.org/js/index.min-da463c4eb025aef55e275ccc8f3b51a0.js:6:10342
1index.min-da463c4eb025aef55e275ccc8f3b51a0.js:8:23959
consoleLog/<()index.min-da463c4eb025aef55e275ccc8f3b51a0.js:8
$ExceptionHandlerProvider/this.$get</<()index.min-da463c4eb025aef55e275ccc8f3b51a0.js:7
processQueue()index.min-da463c4eb025aef55e275ccc8f3b51a0.js:9
scheduleProcessQueue/<()index.min-da463c4eb025aef55e275ccc8f3b51a0.js:9
$RootScopeProvider/this.$get</Scope.prototype.$eval()index.min-da463c4eb025aef55e275ccc8f3b51a0.js:9
$RootScopeProvider/this.$get</Scope.prototype.$digest()index.min-da463c4eb025aef55e275ccc8f3b51a0.js:9
$RootScopeProvider/this.$get</Scope.prototype.$apply()index.min-da463c4eb025aef55e275ccc8f3b51a0.js:9
scheduleApplyAsync/applyAsyncId<()index.min-da463c4eb025aef55e275ccc8f3b51a0.js:9
completeOutstandingRequest()index.min-da463c4eb025aef55e275ccc8f3b51a0.js:6
Browser/self.defer/timeoutId<()index.min-da463c4eb025aef55e275ccc8f3b51a0.js:6

This even happens if I wait long after clicking on the previous job and the loading animation is long gone and the suggestions have loaded.
(In reply to Phil Ringnalda (:philor) from comment #3)
> Bug 1134698, so the race isn't a regression. If you need failures that will
> be slow to load,
> https://brasstacks.mozilla.com/orangefactor/
> ?display=Bug&bugid=1304930&tree=all is generally a pretty good source.

So I suspect that our original implementation of cancel didn't actually work, though I'd have to go back in time to debug. Let's just focus on making sure we do the right thing with the current revision of the code, which is actually a little simpler than it was before (yay angular $resource).
Created attachment 8802604 [details] [review]
[treeherder] wlach:1311436 > mozilla:master
Comment on attachment 8802604 [details] [review]
[treeherder] wlach:1311436 > mozilla:master

I tested this and it does indeed cancel requests.

There may be other panels where we need/want to do this, though you would need to convert the models to use angular $resource if you wanted to use the technique here.
Attachment #8802604 - Flags: review?(james)
Attachment #8802604 - Flags: review?(james) → review+

Comment 8

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

https://github.com/mozilla/treeherder/commit/968b18da42c8672e809f7be5eab8b7166b65affd
Bug 1311436 - Cancel existing query before loading in failure summary (#1936)
Fix applied and is now on production. Please reload to see it.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.