Users getting error: fetchWsapiRecords error: communication failure #18

Activity

1. sherimoore commented on Feb 1, 2019

   

   sherimoore

   on Feb 1, 2019

   More actions

   @tmginzburg We found that if we sort on the Ranking column, this will resolve the issue.
2. tmginzburg commented on Feb 1, 2019

   

   tmginzburg

   on Feb 1, 2019

   Author

   More actions

   The user had his grid sorted by rank, so I don't believe sort is the issue. I had the user test again and it sometimes fails (not always). It is puzzling...
3. agile-eric commented on Jan 29, 2020

   

   agile-eric

   on Jan 29, 2020

   More actions

   This appears to happen in larger workspaces when a user with less than Workspace Admin tries an export that includes the Project column in the view. This seems to be triggering a permissions check that takes so long in a large workspace that it times out. To verify, try dropping the Project column from the view for a user who is getting the error.
4. nikantonelli commented on Feb 3, 2020

   

   nikantonelli

   on Feb 3, 2020

   More actions

   My users are sporadically getting this error when trying to export from this grid:

   fetchWsapiRecords error: communication failure

   They are exporting lowest two levels of portfolio items with user stories. I am able to successfully export the data as a workspace admin, but regular users are getting the error above. It doesn't happen 100% of the time which is making it hard to troubleshoot.

   Hi Terry,

   Eric and I have been looking into this. The conclusion that I came to was that the underlying XMLHttpRequest is timing out beyond the standard 30sec that is set in the SDK.

   There are a few parameters contributing to the timeout:

   1. The timing is done from the browser. This means that any internal company network that takes a while to route your request out of the intranet will add to the problem
   2. The permission of the user. As you have noted, this doesn't happen so often for admins. This is due to extra permissions checks being done for standard users (as opposed to ws or sub admins)
   3. The size of the project hierarchy accessible by the user. By making every node 'Viewer' the amount of checking that is done by the permissions model increases linearly. Twice as many project node permissions means twice as long to check.
   4. The loading on our system. On heavily loaded times, or even coincident accesses by a large number of users can move our instantaneous response time up temporarily.

   The reason for the random nature is that not all of these will happen at the same time, but on occasion they do and then add up to over the 30s.

   The app itself tries to mitigate this somewhat by attempting to fetch 'chunks'. The easiest solution I can think of is to reduce the size of the chunks. However, even though it will reduce the likelihood, this still will not remove the problem entirely if the other factors still add up to more than the time available.

   Eric is going to do some testing, but if you reduce these number in (the app in your subscription) _getChunks code, you can try it for yourself in the meantime:

   maxListSize = 50,
   childCountTarget = 100,

   Thanks,

   Nik