constantly UI refresh

[derakhshanfar]

Hi guys. First of all, a big thank you for creating such a handy dashboard.
I just have a small issue. auto-refreshing in job queues causes some problems. for example, I can't scroll down or inspect jobs in queue lists. is there any way to prevent auto-refreshing or other possible solutions?
I'm using 1.1.2 version

[felixmosh]

This is not reproduces at my side, each update is made at the background and react preserves the UI state untouched

[geminigeek]

i can confirm this is an issue in google chrome win 10 , in firefox its fine. i am using version 1.2.0

[josmas]

I see this all the time on Firefox and Chrome with 1.1.2

@felixmosh it does not happen locally but when connecting to a live site it is just a constant flicker, with tabs showing info they should not, and as @derakhshanfar mentioned, trying to scroll, or even switching from error to data on failed builds is impossible for the most part.

I don't know if this is an artefact of having hundreds of jobs, or the fact that (in our case) we use a hosted redis service and back and forth trips are longer than locally.

[felixmosh]

@josmas Thank you for the info, I will try to reproduce it with long lists 🙏🏼

[derakhshanfar]

@josmas I think if you have more than one queue and you switch tab between them you can replicate this issue.

[josmas]

In my case I do have two queues in the UI. One of them is empty, has never seen a job (it is not hooked up yet) but it is registered.

[mannharleen]

Even I have observed this behavior occasionally. Is this reproducible?

[felixmosh]

Can someone add a reproduction method?

[josmas]

I'll try and prep a script for this, but can't commit to an ETA at the moment.

My gut feeling, after having used this now for about 2 weeks on a more stable deployment, is that this is related to the data coming from the queue changing at rapid pace and forcing a render for some of the tabs.
I saw the unwanted refresh constantly during development, as we had a very high rate of blazing fast failing jobs. Now the queue is a lot more stable, our jobs are rather long (minutes), and the fail rate is very low, so I only see this from time to time. It still happens, but it is more usable.

So the idea here is to modify example.js to push, say 1K jobs (add a for loop in one of the http calls), maybe lower the random sleep time so jobs get processed faster, and see if that shows the issue.
Having said that, I might be totally wrong!

[psytechno604]

I can confirm the issue. Mac OS, Chrome Version 89.0.4389.90 (Official Build) (x86_64)

[felixmosh]

@psytechno604 do you have any reproducible example / notes?

[psytechno604]

@felixmosh it is reproducible with your example - https://github.com/felixmosh/bull-board/tree/master/examples/with-auth

add some jobs, wait until some of them get complete or failed, open COMPLETED or FAILED tab, open "Options" of a job - on the next refresh iteration it will reset to "Data" tab

[WoLfulus]

I think the problem here is how it's setting up the refresh. If you quickly switch tabs (like click in sequence active, delayed, errors), it will at some point refresh the old tab contents before refreshing the active selected tab (you can see this behavior from the network tab). After that it becomes a mess for me.

[geminigeek]

Hi,

I guess clearing the tab/div/panel just after tab click can fix the issue before pulling data and showing !

[mjborys]

I noticed that the refreshes correlate with an API query to fetch data, shown in the recording below (hopefully) with the network tab open so that you can see the effect. Sorry if this is all obvious, just wanted to provide some more info in case it's helpful.

I'm in Chrome Version 89.0.4389.114 (Official Build) (x86_64)
Bull-board 1.4.2
Bull 3.20.0

Screen.Recording.2021-04-08.at.9.12.42.AM.mov

[jorgecuesta]

some new about this? @felixmosh

[felixmosh]

@jorgecuesta I'm not able to reproduce the issue in my local dev env :|

I will give it another try at the weekend

[felixmosh]

Released at v1.7.0

If this issue returns, please free to reopen this issue.

[jorgecuesta]

thanks man!