Handling OSError 113 ECONNABORTED

[Hamsanger]

I am connecting to Microdot running on a ESP32-S3 microcontroller running on a wireless LAN. When the connection to the WLAN router drops out, I get an OSError 113 on the server which is not handled by Microdot. My application catches this in a global exception handler for Asyncio but since I don't know if the Microdot server can recover, I simply crash out of the application. Here is a typical traceback:

  File "asyncio/core.py", line 1, in run_until_complete
  File "/lib/microdot/microdot.py", line 1224, in serve
  File "/lib/microdot/microdot.py", line 1336, in handle_request
  File "/lib/microdot/microdot.py", line 658, in write
  File "asyncio/stream.py", line 1, in stream_awrite
  File "asyncio/stream.py", line 1, in write
OSError: [Errno 113] ECONNABORTED
Quitting
Shutting down

Err 113 is not one of the "MUTED_SOCKET_ERRORS" in Microdot that are explicitly handled. Is this by design? Is it safe to ignore this error and attempt to reconnect the WLAN in the background while leaving the Microdot server app running, or will this cause major memory leaks, etc.?

I am running Microdot on Micropython 1.24.0.

[miguelgrinberg]

I have noticed that the error numbers are not very well standardized in different microcontrollers. See the discussion in #118 for a similar problem to yours. Near the bottom of that thread you can see how one user added 113 to the muted error list and that seemed to help. Other users indicate that this error occurred when the network dropped, which isn't really something Microdot can recover from.

[Hamsanger]

Thanks for pointing me to the previous discussion post. I will try adding 113 to the list of MUTED_SOCKET_ERRORS and re-testing. My application usually handles the WLAN reconnection however Microdot's unhandled exception causes the application to exit before a reconnection can be performed. Effectively ignoring the web request when the error occurs and allowing the application to continue and then re-connect is my preferred behavior.

[miguelgrinberg]

If the exception is not in the areas that Microdot does handling, then it likely means that your wi-fi is gone, which means that Microdot itself cannot do anything to continue. If that is the case, you should wrap the run() or start_server() call that you use to run the server in a try/except block so that you can attempt a reconnection. Once the network is back you can run the server again.

[Hamsanger]

Wrapping the run() or start_server() call does not trap the exception - it is raised when processing a request while attempting to write to a closed stream (refer to the call stack dump in an earlier post).

For the benefit of others reading this thread, the error occurs in the following use case:

• The application is running on an ESP32-S3, Micropython 1.24.0. This port of Micropython raises OSError 113 in the event of a lost WLAN connection (router going down or out of range). Other Micropython ports may not raise this specific error code.
• There is at least one connected web client at the time.
• The web client has requested a page that creates a (persistent) SSE stream connection in which the web server is periodically sending data packets back to the client.
• The WLAN goes down and the web server attempts to send an SSE packet to the closed socket.

The alternative approach of appending the 113 error type to the list of MUTED_SOCKET_ERRORS is successful and this handles the issue gracefully. The web server request handler that is responsible for generating the SSE updates then exits (as if the client closed the connection) and returns the web server to a waiting state. I can then attempt to reconnect the WLAN in the main body of the application after which the web server simply resumes handling incoming requests.

The code to do this looks like:

from microdot.microdot import MUTED_SOCKET_ERRORS
MUTED_SOCKET_ERRORS.append(113) # ECONNABORTED error