Job logs no longer load in background tabs

added Category:Continuous Delivery devopsverify grouppipeline execution groupscalability typefeature labels

I think one thing that makes this worse is some bug where it gets stuck in the loading state. I can't reproduce reliably but I frequently run into this. @rymai also mentioned the same thing in Slack.

Usually, when I see failing builds on an MR, I middle click each failing job so that they open in new tabs. When I switch to those tabs, they sometimes just get stuck at the loading dots.

I know the JS is supposed to start polling again when the tab is visible, so maybe there's some bug.

@engwan Could this be that issue? #293675 (closed)

Ok, so here is a recording I did yesterday. I start by opening a job that's already successful in a background tab (with Cmd+click) and there's no log for 1 minute and 22 seconds (from 00:06 to 1:28) until I refresh the page:

Screen_Recording_2020-12-16_at_17.33.02

/cc @pburdette

Could this be that issue? #293675 (closed)

Probably not because the jobs I was viewing were not canceled / retried. Those were jobs from my MR pipeline that already failed so they were already completed.

Thanks everyone for your feedback. I'm currently chatting with the team on metrics to see if we can continue to poll in the background but continue to not poll if a job doesn't have a trace.

If anyone wants to follow along this might happen in !49982 (merged)

If we revert to polling in background tabs, when the job is done it would stop polling anyway right?

So for most cases (viewing completed jobs), this shouldn't add too much load because it would just poll once.

And this would eliminate the UX problem where you switch to these tabs and you'd have to wait a few seconds for the job logs to show up.

Another alternative is to poll only once for background tabs whether or not the job is done. Then it can continue polling when the tab is visible and the job is still running.

If we revert to polling in background tabs, when the job is done it would stop polling anyway right?

Yes it's always been like this.

We've got a BE only solution in the works that will relieve some strain and help out with UX.

added frontend label

mentioned in merge request !49982 (merged)

removed Category:Continuous Delivery label

ZD Ticket (internal): https://gitlab.zendesk.com/agent/tickets/184397

added customer label

added sectionops label

mentioned in issue gitlab-org/quality/triage-reports#1270 (closed)

mentioned in issue gitlab-org/quality/triage-reports#1278 (closed)

Hello Not sure if its related but for about a week or two, every single time I open a job log in a new tab then switch to that tab, the log is empty and never displays anything. I always have to refresh the page to make it actually stream and display the logs. This is rather annoying because to me this is a regression. Before, the logs were displaying right away and I didn't have to refresh the page every time I wanted to see something.

added severity2 label

added regression regression:13.7 labels

Gave this issue a severity2 since it's pretty visible and the work around is not obvious (it just looks like GitLab is broken). I also gave this a regression because previously, middle-click on a job log would work, but now it doesn't.

I found that it does work but you have to wait 5 seconds. But this is a problem since a lot of times, people cannot wait for 5 seconds and would think it is broken.

I also usually switch to doing other things when I see something taking a while to load. Then when I come back I see that it is still loading. But actually, what I just did was reset the 5 second timer So I have to wait another 5 seconds.

There's also the rare case where it gets stuck as seen in the screen capture video above #294197 (comment 468940260)

For me nothing happens after waiting 5 seconds or more. It gets stuck everytime until I refresh the page.

Anyway, beside the bug where it gets stuck, I don't understand why adding an artificial 5 seconds delay was decided. To me, this seems to be an intentionnal bug that serves no purpose. To alleviate the performance issues regarding polling why don't you just poll less often or stop polling after some time and display a button to start polling again ?