Web UI instability and performance issues

[DavidCo3]

Starting a couple of weeks ago, but really intensifying this week are user interface issues. I am getting bombarded many times daily by our users and have logged tickets for recurring cases of: Users update a task field and it reverts to the old field contents until they refresh their browser, after which it displays the new contents. Users update a task field and it (or a successor task) goes completely blank and needs the page to be refreshed. Sometimes the new data is retained and sometimes it is lost. Users update a field and then try to move to edit another task but they are locked in the current task and can't move. Again, a page reload seems to fix it. We are also still having massive browser freezing issues (related to very high browser memory usage - I suspect caused by Javascript). A fix for this is apparently in QA....we can't wait for this to be hopefully passed into production as this is a bigger issue for us even than the above task/field editing There's also another thread raised on this forum regarding report prompts intermittently not working in Chrome. Fun times.....

[jrieth]

We too are experiencing each of the issues descibed by David Cornwell on a daily basis. Perhaps it's time to consider reverting the recent changes to time line recalculation? ~Jeff

[HeatherRe]

We are experiencing the same problems in our instance described by David plus a high volume of incidents reported due to the following errors: (a) Save failed because someone else tried to save this project at the same time (b) Request Error: response status 504 (c) Request Error: response status 500 (d) Request Error: response status 0 (e) Err_Insufficent_Resources error We started experiencing performance issues back in Dec 2015 and the tickets are still open pending resolution. We spent a significant amount of time troubleshooting the issues with our own network team and found that it wasn't on our side. Really looking forward to the performance of the tool improving sooner rather than later. Thank you for posting your original comment and getting the conversation going. Good to know it isn't just us!

[EXP_-_TylerOg]

Hi all -- Based on the feedback provided in the original post and following replies, these issues appear to be related to a few of the defects that have been escalated to our Development team (as David mentioned, one of them being in QA as we speak). I understand the frustration of the timeliness, so I definitely suggest bringing this feedback to our Support team in the "https://support.workfront.com" form of a support ticket so that we can verify the issue and get it attached to the original defect. The more information we have on a defect that we can forward to Development, the quicker we'll be able to get a fix created and pushed out. Thanks everyone! Tyler

[Mohini__Mini_Si]

We've been having a lot of issues with users changing a Commit To date, but the system keeps reverting to the original Commit To date and the user keeps getting overdue notices even though the date had changed.

[JasonMa]

We have been seeing issues similar to Heather's on a regular basis. As strange as it sounds, these issues tend to be worse in the evening (I am on the East Coast) starting around 4PM Eastern and getting worse as the evening goes on. In particular, it is gets bad around 9:30-11PM Eastern. I also notice them more mid-week, mainly because I have to do project updates on Tuesday evenings. Not sure if anyone sees something similar or if this helps out the team working on the issue, but thought I would mention.

[KatherineHa1]

We are experiencing the same: Users update a task field and it reverts to the old field contents until they refresh their browser, after which it displays the new contents. Users update a task field and it (or a successor task) goes completely blank and needs the page to be refreshed. Sometimes the new data is retained and sometimes it is lost.

[DavidCo3]

OK, I'm glad (for what it's worth) to know that it isn't just us. As Tyler said, please make sure you log each case with Workfront Support so they see the volume of customers affected. We get a few red error bars at times saying there is a database error relating to eclipse. I report each to support also. I'm addition we are getting more and more of the black message bars saying to wait while the system is updating.... I would like to see some sort of feedback from senior Workfront people regarding both performance and integrity issues as they seem widespread with other global Workfront customers (we are mostly in Australia but with users globally too).

[CommunityUs]

Hi Everyone, I've created a support ticket, but thought I share our issue as I didn't see it previously menitoned. Over the last couple of weeks, we've noticed that we've had to manually adjust our projects to reflect accurate projected (start & end) dates. Issue: Actual start dates aren't being updated when the following actions were taken: - Added a % (less than 100) to task completion field. Actual start date did not update (it used to) - Changed task status from New to In Progress. Actual start date did not update (it used to) Thanks!

[EricLu2]

<> May I assume the project Update Type is set to “Automatic and on Change”. Do the dates update correctly when you select Recalculate Timeline from the Project Actions menu? Is there a Task Constraint forcing a date? Is there a parent with a forced date? I’ve opened a number of similar tickets and found out that I had a setting that prevented automatic recalc, or had a parent task with a task constraint/forced date. It became something of a joke between Ruben (great tech support guy) and me, sad to say. In the year of me opening tickets for this issue, it has never turned out to be a WorkFront software issue, darn it. The Actual Start date is set the first time you set the percent complete to a non-zero value or move the project from New to In Progress. I’m not sure you can reset that actual start date once it is set. The actual start date, as you point out, impacts the projected completion dates. I’d be interested in knowing more about the issue you are experiencing… Thanks, Eric

[CommunityUs]

Hi Eric, Thanks for your comments. Here are some answers to your questions: Q: May I assume the project Update Type is set to “Automatic and on Change”. A: The project update type is "Change Only" Q: Do the dates update correctly when you select Recalculate Timeline from the Project Actions menu? A: No Q: Is there a Task Constraint forcing a date? A: There is a dependent & enforced task, but its is 100% Complete, so there should not be any issue with the start date Q: The Actual Start date is set the first time you set the percent complete to a non-zero value or move the project from New to In Progress. I’m not sure you can reset that actual start date once it is set. The actual start date, as you point out, impacts the projected completion dates. A: Agree, but unfortunately the actual start dates aren't changing when you add a percent complete. I played around with it a bit and was able to reset it, but it was messy and I'm almost embarrased to say how I got it to work... (eek!) But here goes. IF you change the task 100% complete let WF recalculate the dates and then change it back to 0%, the projected dates reset and work as expected (I know this makes no sense). It appears to be a WF bug, but if you have any other thoughts, I'd love to hear them. I guess the last thing that I'd say, is that we've had the same project settings for months and we just started seeing a different output. We noticed this happening a couple weeks back. Hope that helps.

[EricLu2]

Hi: Great detail, thanks. Sounds like a bug to me! Every Monday morning I wonder what is going to be different this week. No one in Tech Support knows what might have changed in the prior weekend. The people who know what changed each weekend aren’t communicating to the people who work with customers, much less communicate with customers. Sure, we know about SOME of the changes that are made during releases, but I’ve been told that WorkFront drops new code most weekends without announcement. I was told once that they dropped 20K lines of code on a Wednesday night. Best wishes for a quick resolution. Eric

[NateBa]

Just FYI, I've put together a blog post explaining how we're going to be helping to remedy a lot of the issues you've brought up here. It should go up in a few days. Until then, I thought everyone in this thread would appreciate being involved in the upcoming product release webinar next week. Other details about things we'll be doing to provide more transparency are forthcoming. I'll be keeping the Events section current with upcoming webinars and events that are relevant to the community, so please try to keep an eye on it. In Reply to Lucas Eric:

Hi: Great detail, thanks. Sounds like a bug to me! Every Monday morning I wonder what is going to be different this week. No one in Tech Support knows what might have changed in the prior weekend. The people who know what changed each weekend aren’t communicating to the people who work with customers, much less communicate with customers. Sure, we know about SOME of the changes that are made during releases, but I’ve been told that WorkFront drops new code most weekends without announcement. I was told once that they dropped 20K lines of code on a Wednesday night. Best wishes for a quick resolution. Eric

-Nate Bagley --- Workfront Community Manager - Work Smart, Work Happy Message me directly at:

[DavidCo3]

A quick update specifically on the browser freezing issues is that they seem to be resolved (in the Preview Sandbox) and will be in Production next week. Very happy that there is progress here, so thanks to the Workfront Support and Dev teams for getting this fix out there.

[NateBa]

Thanks for the update David! I'll pass on the kind words to the Dev team. In Reply to David Cornwell:

A quick update specifically on the browser freezing issues is that they seem to be resolved (in the Preview Sandbox) and will be in Production next week. Very happy that there is progress here, so thanks to the Workfront Support and Dev teams for getting this fix out there.

-Nate Bagley --- Workfront Community Manager - Work Smart, Work Happy Message me directly at:

[KarlenRu]

Nate, When will this blog post be up? My users are very frustrated by performance issues in the system (started about 3 weeks ago) and being able to communicate a plan that Workfront has committed to would be very helpful. Also, is there a specific date that the browser freezing fix will be in Production, since it was mentioned it would be this week? I am looking for it but don't see it yet. thanks, Karlen

[HeatherRe]

Nate, I echo the comments made by Karlen. Just this week, we had received news that one of our bug tickets (Page Unresponsive Error) was transferred over to a Product Feature Request because the fix for the issue 'requires a massive amount of work, so the development team decided to accomplish it not in the frames of an issue but as a larger work item'. No ETA was provided nor is it available on the Product Feature Request > Extreme System Performance Slowness for Task List, Page Unresponsive error (Product Feature Request Ticket #16497449). Hoping you can shed some light on this for all of us. Heather

[DavidCo3]

Does anyone know if the software update has already been released? We have not seen the expected improvement in performance yet. In fact, our users are complaining about receiving many new error messages this morning.

[DavidCo3]

The update now seems to have finally been applied at around lunch-time today. So far, so good in terms of the browser freezing issue being resolved.

[LindaWa]

We see a lot of this also. Especially when creating or updating user profiles. very frustrating.

[EXP_-_TylerOg]

Hi all -- Just wanted to reiterate to everyone that these issues appear to be related to a few of the defects that have been escalated to our Development team. We definitely understand the frustration that this causes, but best way for us to be able to address your concerns will be by bringing this feedback to our Support team via a support ticket so that we can verify the issue and get Developer eyes on it. Thanks and have a great holiday weekend! Tyler