An error: onrequestread connection reset by peer message is one of the more confusingly convoluted issues to debug within the R language. However, the most difficult aspect of the error isn’t dealing with it. The real trouble simply comes from understanding what it means in terms of stability and performance within an R script. And it’s generally a less serious error than you might assume. The issue tends to simply point to a browser abruptly closing a network connection with the underlying Rshiny framework. However, there are variants on the issue and it’s important to investigate it to make sure that everything is running as intended.
An Overview of Shiny’s Connection Errors
Part of what makes the connection error a little difficult to understand is the nature of how R’s being used when it’s generated. R is typically run through the command line, an IDE, or as a scheduled job. But the Rshiny framework makes it easy to turn standard R code into a full web app. It’s not a totally seamless process though. Turning a command-line-based script into a web app adds numerous extra frameworks, communication protocols, and client platforms into the mix. And any, or all, of them might produce errors at any given time. What’s more, the error messages aren’t always going to be seamlessly translated through the various communication bridges linking them together. You may well find yourself alerted to an error but without R’s typical clues about what the error is doing or how to fix it.
Consider how different Windows, OSX, and Linux are from each other. How different each of their infrastructures, communication protocols, file systems, and most especially error messages are. That’s the general level of difference between some of the systems that web apps interface with. The R interpreter and a browser’s JIT compiler are two very different runtime environments. But both are going to be used within the context of a Shiny web app. And that’s only two of many different large, moving, pieces.
In the case of a connection reset by peer error the message generally refers to the connection between a client system and the shiny GUI process. The error can occur when a browser suddenly leaves the site your app is running on. But it’s also important to keep in mind how the modern web works. Web apps don’t simply run within a single process. Any web app is going to continually send and receive data. This can range from raw text and numbers to graphical elements. Even data formats sent through the web, like JSON, are almost like miniature databases unto themselves. So when you’re connected to a shiny app it might feel like one browser connected to one app. But in reality, your browser contains a multitude of different processes communicating with just as many elements of the R app. And the real kicker is that any of those processes might trigger a connection error if it isn’t successfully processed.
Fixing the Connection Error
Thankfully fixing the issue is usually far easier than the initial diagnosis might lead someone to believe. One of the easiest ways to fix the problem is to simply ensure that you’re using the latest version of your browser. Both Chrome and Firefox put a lot of work into the systems that are most commonly used with web apps. As such, it’s quite possible that a bug might sneak in. But when it happens the bugs will typically be found and fixed rather quickly. All of this means that you should always update to the latest browser version before proceeding with any other testing. It’s also a good idea to test with multiple browsers if you’re able to. And it’s especially important to test with both desktop and mobile-based browsers. The different architectures and implementations can often point to the source of the problem. Likewise the fact that one environment will typically use your standard wired ISP and the other your mobile data connection.
Make sure to keep an eye on the console during the testing process too. It’s important to note when errors appear and if they’re triggered by any unique and repeatable action. The more you can narrow the variables down the better.
You should also look into the different views offered by Shiny. For example, if you run your app in a window view you might be at less risk of seeing the error. While using the external or viewer pane might increase the chances of the error showing up.
The error can also appear when there’s some form of network interference. For example, some servers might automatically throttle IP addresses that make too many requests in a short amount of time. If the previous fixes don’t take care of the problem then that’s generally the next area to look into.
Likewise, the error can appear as an issue with the app’s ability to accept requests. This is the flip side of how a client’s inability to send requests can trigger the error. If testing on the client side doesn’t work then you should try updating every component of your app. From the R system to the libraries you’re using and Shiny itself. Even restarting the app or the entire server can sometimes solve this issue by resetting every element of your app to its initial state on the server.
Shiny also has some extra debugging functionality that might be able to help you hone in on any given problem. For example, you can try using the following to create a debugger prompt after an error occurs.
options(shiny.error=recover)
You can also look into elements of your underlying system that could cause instability for general applications. The biggest of these is available RAM. But pushing the CPU to its limits can also result in instability within other running programs. If you’re only seeing the error at select times you could check to see if you have automated processes running during that period which might use up all of your available resources.