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.
Component: Treeherder → Treeherder: Data Ingestion
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
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).
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)
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.