Shiny app disconnects only on server--logs show no errors

I have a secure app hosted that disconnects very randomly and infrequently based on some (validated) user inputs. Everything works fine on my desktop--the problem only occurs on the hosted app.

The app looks at historical load data from a logistics company and uses this data to suggest the best companies to call based on the following input parameters:

Zip of Origin *
Zip of Destination *
Equipment Type *
Load Weight (lbs)
Total Amount to Bill

*mandatory fields

For some combinations of zipcodes and equipment types the query will run fine, but when I click on the table to display a map of that companies recent routes, the app will disconnect without throwing any error at all (despite my best efforts to track these errors).

I have spent many hours trying to figure out why certain cases fail (there is nothing special or different about the failing cases), and I'm still stumped. Reversing the zips, using nearby zips, or changing the date range or equipment type all work without disconnecting.

The browser console shows the following error, but is not overly helpful (I can't upload a screenshot due to my status as a new user):

"Failed to load resource: the server responded with a status of 500 ()"

I've tried on all the common browsers and the error is the same. This is not a memory issue because there is nothing written to the logs.

*due to sensitive data, I cannot post a working example (I would create a mock-up app, but then the problem would be non-existent since I am unable to replicate the disconnect).


Can you please tell us what version of shiny are you using?

Shalu Tiwari

App was deployed using Shiny version 1.1.0
App was built using R version 3.5.1 (2018-07-02) -- "Feather Spray".

I re-deployed the app after updating to Shiny version 1.2.0, but nothing changed.

Can you provide information about how you are deploying and hosting the application?

I am using the rsconnect package within Rstudio to deploy to a paid account on

Is there a specific file that the browser is trying to download which gives the 500 status message? If you could include a screenshot of the JS console, that would help.

It's not downloading any files at the point that the error occurs. Here is a screenshot of the error message:

Also, since you are a paying user, you can also contact to get help with this issue.

It's possible that the problem is due to a problem in rhandsontable, or an interaction between rhandsontable and, but it's hard to tell which without I know it's not easy to do so with this particular application, but it would really help to have a reproducible example. That would let us get in there with a debugger and figure out what's going on.

Here's information about how to do that:

If you're familiar with debugging JavaScript in the browser, you could put a breakpoint at rhandsontable.js:215, and when it gets there, see if there are any weird values that are being passed to onInputChange.

Other possibilities include updating your version of rhandsontable.

One more question: do you have a reliable internet connection?

Thanks for the tips. I hadn’t realized I could get help via

I am not familiar with debugging JavaScript in the browser, but I will try to learn more about that.

I can’t post a MWE because the error is so isolated that I have only been able to reproduce it on 3 out of nearly 1000 queries and the data is sensitive so I also can’t just share the whole app.

I’ll try updating rhandsontable.

My internet connection is great.

What do you see in your application's logs?

The logs haven't been helpful at all. I'm attaching the logs for a successful query followed by an unsuccessful query. I don't think you'll be able to tell a difference.



I think it makes sense, however, that the logs wouldn't be helpful since the app works fine in Rstudio and only disconnects when hosted on the server.

One thing that is odd about the unsuccessful query is at timestamp 20:01:51.07104. The line should start with either SEND or RECV, folowed by some JSON, but instead it looks like it's simply starting in the middle of some JSON, beginning with the text om database"]}. I suspect that there's a malformed message being sent to the browser. When running an application locally, it uses the browser's WebSocket implementation, but with, it uses the SockJS library to emulate the WebSocket, and it's possible that it's not as robust at handling malformed data.

I know it might be hard for you to find out, but do you know if there are any strange characters being sent there?

This was my initial guess as well--that there was some sort of irregularity in the data associated with the failing records.

Prior to posting here I spent a lot of time checking the data being processed when the app disconnects and I haven't been able to detect anything irregular or different about the cases when the app fails.

I've been poking at it some more, and it looks like there might be a bug in where it has a problem with the specific data being sent from the browser to the server. I'll keep investigating and keep you updated.

Thanks Winston! Looking forward to seeing what you find!

This sounds an awful lot like a bug that we've seen reported from other users. In short, the bug seems to be that certain text content can cause our proxy servers that front applications to choke and blowup with this LUA error. We've seen this reported mostly in the context of file uploads, so it's interesting that it seems to also happen with JSON data.

Is there anything odd about this data's encoding or content-type? Or any other properties that might cause an issue for the proxy?

The table displayed in the app comes from three different sources--all CSVs hosted on dropbox. There is no special encoding since there are no special characters in the data.

Inspection of the records in the table when the app disconnects fails to show any irregularities.

Not sure of any other properties that could cause an issue. Feel free to run the example queries I've provided at the link I've shared in the private messages regarding this issue.