UI doesn't update when builds start/end/fail - require full page reload

To add some detail here, I am getting many

net::ERR_BLOCKED_BY_CLIENT

errors for POST requests to https://api.segment.io while on CircleCI and I think this has to do with this issue. Also, turning off AdBlock seemed to help (less errors in the Chrome Debug terminal and updates more often).

2 Likes

Thanks Joshua, I’ve added this information to the bug report.

I noticed that some requests were being blocked, and disabled my ad blockers. Those requests stopped showing up as blocked, but disabling ad blockers did not actually seem to have any impact on the issue overall. It seemed to behave the same, with only the timer for running jobs updating, and no other status updating.

I did notice that, on rare occasions, if the page is left for quite some time, that eventually it sometimes updates. But after that it will again hang, and no longer show updates to status, no new jobs/workflows, etc.

And…the issue does appear to be ongoing still. I find myself hitting reload quite a lot on CircleCI these days just to keep track of the progress of my various workflows. It also seems that CCI servers start to see my refreshes as an attack after a while, or so I’m assuming, as after that it seems like my ability to refresh is broken until I leave things alone for about 15-20 minutes then try again.

Has there been any progress identifying what the issue here is?

Not yet. It’s still in the next up queue, but as we are working on a new UX design I think that team is waiting to see if it’s still an issue first after that is rolled out, rather than doing work that could get replaced and be not the best use of time.

Thanks for the update! Looking forward to the new UI. :slight_smile:

I am chiming in again about this issue, “again” because I’ve posted on another topic that was also discussing this issue. First of all, I’m sorry for the exasperated/frustrated tone of my message.

I disagree with waiting to see whether the new UI solves the issue.

First, it looks like waiting for some kind of magic or miracle to happen, which is unsettling to me because it hints at the team not having an idea as to the root cause of the issue, or not willing to look for it.

Second, I’m wondering what would happen in case the new UX does not happen to solve the issue as a side bonus? It will only be more weeks and months lost waiting for a fix.

Third, this issue has been around for almost two months. I guess that the numbers should speak in favor of not letting it linger. How many users are impacted? How many builds were started in six weeks? How many customers jumped onboard to this dashboard instead of the one that was working? How high should these numbers get before the situation is deemed unacceptable?

Late March, there were supposedly only two higher priority issues. This is May and the issue is still here and my team and I are still in the same position than when the issue surfaced. And it seems from the last update that fixing the issue has been indefinitely postponed.

I understand the notion of “the best use of time” but is there nothing being lost in the meantime customer-side? Is the expected release date of the new UI known? How close is it to completion? My point here is that [I believe that] restoring such an essential feature in the current UI trumps any concern of efficient use of time.

But again, many apologies; this is just the opinion of a frustrated development team manager.

3 Likes

Similarly to you I don’t want to have a go at fellow laborers but if we had such an issue on our product I would feel customers had every right to be quite angry at this point. The UI does not accurately reflect build status/es - this is a significant bug.

I’d like this to get fixed regardless of some sort of UI update. Core features working should always trump UI. I think as a product that is essentially for other developers the product management team would understand this.

2 Likes

We’ve been using nativefier with CircleCI for a while, and it’s great. Luckily, nativefier also makes it easy to fix this issue locally.

You make a local JS script called reloadPageInactivity.js with the following (based on StackOverflow):

var refresh_rate = 30; //<-- In seconds, change to your needs
var last_user_action = 0;
var has_focus = false;
var lost_focus_count = 0;
var focus_margin = 10; // If we lose focus more then the margin we want to refresh


function reset() {
    last_user_action = 0;
    console.log("Reset");
}

function windowHasFocus() {
    has_focus = true;
}

function windowLostFocus() {
    has_focus = false;
    lost_focus_count++;
    console.log(lost_focus_count + " <~ Lost Focus");
}

setInterval(function () {
    last_user_action++;
    refreshCheck();
}, 1000);

function refreshCheck() {
    var focus = window.onfocus;
    if ((last_user_action >= refresh_rate && !has_focus && document.readyState == "complete") || lost_focus_count > focus_margin) {
        window.location.reload(); // If this is called no reset is needed
        reset(); // We want to reset just to make sure the location reload is not called.
    }

}
window.addEventListener("focus", windowHasFocus, false);
window.addEventListener("blur", windowLostFocus, false);
window.addEventListener("click", reset, false);
window.addEventListener("mousemove", reset, false);
window.addEventListener("keypress", reset, false);
window.addEventListener("scroll", reset, false);
document.addEventListener("touchMove", reset, false);
document.addEventListener("touchEnd", reset, false);

Then you run nativefier:

nativefier https://circleci.com/gh/RuneAI --internal-urls "(.*?)(github\.com|circleci\.com)(.*?)" --name "CircleCI" --inject reloadPageInactivity.js

Voila! You now have a local CircleCI app that refreshes after 30 sec of inactivity. Hope that’s useful to anyone.

3 Likes

Good work! :trophy:

1 Like

@drazisil Any update on the redesign? Dashboards outright don’t work if they don’t automatically refresh.

Sorry for the silence, I was on vacation, but I see it’s been escalated while I was away)

I understand the frustration, and I may have mispoke when I said that the team was waiting on the new UI. The team responsible for this will be looking at it soon (still in nextup), and we will hopefully have an update/fix shortly, but I do not want to put a timeline in another team’s mouth as we still don’t know what’s causing this.

Hi Folks!

I’m told this should be fixed, can you please confirm?

3 Likes

Yes! It works as expected! Thank you!

1 Like

This appears to be automatically updating individual jobs for me when I’m viewing a workflow run instance, but the main workflow dashboard with all the branches and list of all workflow runs still isn’t updating automatically.

Hi Adam,

Can you try clearing your cache and open a ticket if this persists? I think this is a separate issue.

I tried clearing my entire cache, and it’s still persisting. Isn’t this issue directly related to what I described above (UI not automatically updating)? A build started, it completed a while ago, with that branch selected the UI still says it’s running, and that latest build never appeared in the left hand sidebar.

This issue was related to the job details not updating. The dashboard uses different technology and thus would be a separate issue.

It looks like two issues did get mixed in this thread though. Let me dig deeper.

1 Like

Thanks again fellow workers! Working for me :fist:

2 Likes

I can confirm that after about 6 weeks this is finally working for me again and the UI is updating when new jobs start/complete. Thanks!

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.