Hi - any word on when this might be fixed - it’s starting to get really really annoying. All our builds are now multi-step workflows. Hitting page reload every 30 seconds to see whats going on is not a great experience.
Hi Andy. The team is testing some fixes they think may solve this, so I’m hoping it is resolved soon. I agree it’s pretty frustrating.
I have also been experiencing this, going on for a couple of weeks now. The issue has been occurring today, and is quite pervasive throughout the entire CircleCI web ui. Nothing seems to update automatically anymore, any changes in status (even when interacting manually, such as manually canceling a job or workflow) requires manually refreshing the site to actually see the correct status on the web page. This has effectively rendered all the various dashboards in CircleCI unusable, as the only things that seem to update are run timers…and even those will count past the completion time of a job if the site is not refreshed.
I’ve been affected by the screen refresh issue, probably for around the last six weeks. I assumed it had been turned off deliberately, since it affects me in Firefox/Mint and Firefox/Win10.
Of course, it is rather an overstatement to say that the system is unusable. It’s a minor inconvenience, but it’s not an emergency (I click on a different screen and then click back again). Carry on!
Well, I don’t mean to make the situation sound too dire.
I do, however, see a dashboard as a tool that keeps you informed, and generally “informed at a glance”. Right now, with the issue as it exists at present, the CCI dashboards are not keeping me informed. They are indeed keeping me with my finger on the refresh button every minute or two, but they are otherwise not doing their job to keep me informed at a glance, and we often have numerous builds for multiple projects in progress that we are waiting on.
I’ve been in the same boat today, spamming refresh buttons on the CCI site. I am wondering if there is a deeper issue here. Half the time when I refresh a page, I’ll get a spinner or two in various different areas of the dashboard and they will just spin and hang. Sometimes this will last for 5-10 minutes before I can get the site to actually respond again. I am not sure if this is just a byproduct of an increased number of CCI users doing the same thing I am…manually refreshing the site to get current status, so the CCI web servers are getting overloaded? Or is this indicative of a potentially deeper issue with CCI’s dashboards?
This is/was also being discussed here:
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).
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.
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.
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.
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.
Good work!
@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?
Yes! It works as expected! Thank you!
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.