... now the CL has the rights try jobs associated; so the wrong ones were associated with it very briefly only (and now I'm starting to doubt my eyes - was this real?)

marja@ i believe you, but I don't know what can be done about this now.

AFAIU, "git cl try" effectively resulted in CQ dry run, which resulted in triggering new tryjobs, which couldn't have become instantly green (and CQ timelines shows that). 

Since those tryjobs that filled your screen instantly were green, some mishap happened at UI side.

I think I saw something similar once or twice over last 6 months if I keep navigating back and force between changes in polygerrit **in the same tab**. But I couldn't and still can't repro that.

I assigning to Andy who understands polymer side better.

However, if you ever see it again && I am around, feel free to interrupt me and show your browser.

Seeing this again!

Clicking a link here: v8_linux64_asan_rel_ng_triggered in
https://chromium-review.googlesource.com/c/458003/ (which is not even my CL)

I get this try job:
https://build.chromium.org/p/tryserver.v8/builders/v8_linux64_asan_rel_ng_triggered/builds/17681

which is a failing try job for one of my CLs:

https://chromium-review.googlesource.com/c/457037/

Aha, turns out the CL where the try job links are is not even supposed to have try jobs!

The nature of this bug is such that other users are never able to replicate the bug that the reporter is seeing. It's something with local cached values. You had viewed your CL (457037) and loaded its tryjobs; then you went to the other CL (458003) and the browser+js+webapp+whatever conspired to believe that you should be shown results from the first one.

I'm not sure if it is the extension js holding on to the wrong change object and polling for builds with the wrong tag, or if it is another system holding onto the results of the previous polling and rendering them, or if it is something else entirely. I won't be able to debug this until I see it for myself.

If this happens to you again, please open the network tab. The tryjob extension should be polling (about every 10 seconds). Watch for one of those polls to happen, then copy the url it is polling and put it in this bug. That will help eliminate one of the possibilities above.

This is happening really frequently for me now. Trying to pull in more information...

Maybe the same as  http://crbug.com/700890 

Here's a copy of one of the events I see on the network tab, but not sure what to make of it..

I'm at https://chromium-review.googlesource.com/c/459616/ and I get these:

Request URL:https://chromium-review.googlesource.com/changes/I4b22be4ec2b55a2aeb003b23b2528cef6df29138/detail?o=SUBMITTABLE
Request Method:GET
Status Code:304 
Remote Address:[2a00:1450:400c:c09::52]:443
Referrer Policy:no-referrer-when-downgrade
Response Headers
alt-svc:quic=":443"; ma=2592000; v="37,36,35"
content-disposition:attachment
date:Fri, 24 Mar 2017 12:34:46 GMT
server:GSE
status:304
strict-transport-security:max-age=31536000; includeSubDomains; preload
x-content-type-options:nosniff
x-google-backends:/bns/wl/borg/wl/bns/gerritcodereview/prd.gerrit.frontend/1,wlgq129:4808,/bns/wl/borg/wl/bns/gerritcodereview/gfe/0,wmc130:443
x-google-cookies-blocked:_ga=
x-google-cookies-blocked:_ga=
x-google-dos-service-trace:gerritcodereview:prd_gerrit_frontend,main:gerritcodereview-gfe
x-google-gfe-request-trace:wmc130:443,wlgq129:4808,/bns/wl/borg/wl/bns/gerritcodereview/prd.gerrit.frontend/1,wlgq129:4808,wmc130:443
x-google-gfe-response-code-details-trace:response_code_set_by_backend,response_code_set_by_backend
x-google-gfe-service-trace:prd_gerrit_frontend,gerritcodereview-gfe
x-google-gslb-service:prd_gerrit_frontend
x-google-netmon-label:/bns/wl/borg/wl/bns/gerritcodereview/prd.gerrit.frontend/1
x-google-servertype:prd_gerrit
x-google-service:prd_gerrit_frontend,gerritcodereview-gfe
x-google-session-info:COKJ68CgAxCdAxoJGAEoCTCI3PFHMPKtxMYFggEWCJ2Gnef23or5vgEQ2paCkKaL_ouQAYgBAagBArIBD0lPS1VrNUxEeDZ6ZDZnRboBAggCwAEB
x-google-shellfish-status:CIgCQEY
Request Headers
Provisional headers are shown
Referer:https://chromium-review.googlesource.com/c/459616/
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.98 Safari/537.36
Query String Parameters
view source
view URL encoded
o:SUBMITTABLE

That's not the network request for the tryjobs, that's the request for the change object representing the whole code review. The good news is that it is requesting the correct change object (but we knew that, because it is displaying the correct change). What we still don't know is whether the requests to buildbucket are for the right change object.

Look for requests like "https://cr-buildbucket.appspot.com/_ah/api/buildbucket/v1/search?max_builds=500&fields=builds(failure_reason%2Cid%2Cparameters_json%2Cresult%2Cstatus%2Ctags%2Curl)&tag=buildset%3Apatch%2Fgerrit%2Fchromium-review.googlesource.com%2F459616%2F1"

 Issue 689638  has been merged into this issue.

This is definitely a regression and a serious issue, but we seem to be having trouble gathering reproduction info. That suggests that it is either impacting a small subset of the current userbase, or appears rarely. Because of that, we're not going to block the beginning of dogfood on this issue. Instead, we're going to move it to -Launch, raise its priority, and hope that the additional userbase gives us enough information to track this down and fix it. Hopefully it will be one of the first issues we fix after beginning dogfood.

 Issue 696613  has been merged into this issue.

Highlighting once more that this maybe just issue  http://crbug.com/662771 . Not that this gets lost. It depends on which wrong trybots are shown? Random ones? Or trybots from an earlier patchset of the same CL or another CL the user was looking at earlier? It it's the latter cases, I'd guess this is a dupe of  http://crbug.com/662771 .

The reports filed above definitely suggest that it was displaying tryjobs from one CL on a *different* CL that wasn't supposed to have any tryjobs on any patchset. But again, no one on infra team has managed to replicate this or capture the network traffic that we need to see (see comment 11) so we can't fix it yet.

See repro https://bugs.chromium.org/p/chromium/issues/detail?id=700890#c6 - if you have an hour you can try it out.

I think you can look at any CL showing some trybots, let the token expire (wait one hour), then navigate to some other CL. It's just important that you don't refresh the browser. I think there are scenario's where you can click on e.g. Your->Changes on the top of the page and choose another one, without the token refreshing.

I didn't confirm this yet, but I have a gut feeling that I went through a similar scenario.

Thomas: does your experience seem to corroborate Michael's theory that this only happens after the tabs have been open for >1 hour and the token has expired? Or does this happen when you're just clicking between a lot of tabs even if they are all recent?

Tried out the repro from comment 17 today. It's quite simple:
- Open any CL showing some trybots in a tab
- Do other stuff for 1 hour
- Go back to that tab and navigate with any button in gerrit frontend to other CLs and the trybots will hang, e.g. click Your->Changes and select any change, or navigate to the Watchlist, or even changes from other projects. As long as you don't refresh the tab, the old tryjobs will stay.

Great. Thank you for the reliable repro steps!

The following revision refers to this bug:
  https://chromium.googlesource.com/infra/gerrit-plugins/buildbucket/+/c39883c28c004e1b58ff5925d6f72a4e5bb45fae

commit c39883c28c004e1b58ff5925d6f72a4e5bb45fae
Author: Andrew Bonventre <andybons@chromium.org>
Date: Thu Apr 27 20:02:15 2017

Refresh auth token when it expires

Also adds additional unit tests for untested components.

Bug:662771
Bug:680664
Bug:692980

Change-Id: I3dc2ea87a73953a4b4692694d89e4636352d5bcb
Reviewed-on: https://chromium-review.googlesource.com/486986
Reviewed-by: Aaron Gable <agable@chromium.org>

[add] https://crrev.com/c39883c28c004e1b58ff5925d6f72a4e5bb45fae/src/main/resources/static/cr-buildbucket-client.js
[modify] https://crrev.com/c39883c28c004e1b58ff5925d6f72a4e5bb45fae/src/main/resources/static/cr-tryjob-picker.js
[modify] https://crrev.com/c39883c28c004e1b58ff5925d6f72a4e5bb45fae/test/cr-buildbucket-view_test.html
[modify] https://crrev.com/c39883c28c004e1b58ff5925d6f72a4e5bb45fae/src/main/resources/static/cr-tryjob-picker.html
[add] https://crrev.com/c39883c28c004e1b58ff5925d6f72a4e5bb45fae/src/main/resources/static/cr-buildbucket-client.html
[modify] https://crrev.com/c39883c28c004e1b58ff5925d6f72a4e5bb45fae/src/main/resources/static/cr-buildbucket-view.html
[add] https://crrev.com/c39883c28c004e1b58ff5925d6f72a4e5bb45fae/test/cr-buildbucket-client_test.html
[modify] https://crrev.com/c39883c28c004e1b58ff5925d6f72a4e5bb45fae/test/index.html
[modify] https://crrev.com/c39883c28c004e1b58ff5925d6f72a4e5bb45fae/src/main/resources/static/cr-buildbucket-view.js

This has been fixed and verified on canary-chromium-review.googlesource.com. Will mark as verified when deployed.