Client disconnect - request timeout - no longer httpcontext available

Client disconnect - request timeout - no longer httpcontext available

  

Hi all,

I have an app in which the user takes photos. They are stored as binaries in a local database table. Using the silk UI asynchronous offline sync actions and the auto-generated table sync actions that table is sent to the server. I have tweaked those actions slightly such that on the server-side they call custom CRUD actions which don't actually save the binary, but just facts regarding the image + an AWS bucket filename, and the actions either upload or download to AWS (all in an aim to keep the storage consumption down in the database).

I am getting the front end crashing (Edit: sorry, I should say they SOMETIMES get a crashing error, not always - in fact I haven't personally seen the issue, but then my camera on my phone is small and my internet is very quick - I believe the users experiencing the issue are using iPhones and are on slow connections). Users are just testing at the moment using Outsystems Now (apple enrollment taking an age - a month and counting!) anyway, so I am examining logs to see what happens and this is the error at the time:

"The client is disconnected because the underlying request has been completed.  There is no longer an HttpContext available."

I have found some forum entries and people suggest extending the timeout on the actions. I am yet to isolate the exact action and I'm about to start adding some logmessage events to track down the exact subroutine that takes a while.

While I'm happy to extend the timeouts for that call to make sure users on poor connections can get sync, I'd rather that even if the timeout occurs that it didn't literally crash the front end! Even if I give that function a 600s timeout some will probably exceed that and most of the users wont even know how to close an app and open it again. Ideally the action would just gracefully fail the sync attempt and perhaps succeed the next time an offline sync occurred.

Do I need to do better exception catching? If the upload failed I would rather the sync knew about it and wound back any changes made to .IsModified attributes (and the others) as appears to be the case during more graceful failures.

Thanks for any advice anyone can give me, as always very much appreciated!

Hi Danny,

are you still having issues or did you manage to solve it?

Hey Danny,

Same issue here. Did you manage to solve it?

Not really! I extended limits, wrote my own sync actions which split things up and try to do things individually, I think I still am sometimes hitting issues. Users not so good at reporting things when they are rare though.