[ST Edge] - Fatal error from socket.http

Fatal error from socket

This error can occur when using http.request from socket.http. It doesn’t occur at the point of the call, but rather some random time later after an http request fails - most probably due to timeout.

FATAL Web Requestor S  Lua: runtime error: [string "socket"]:205: received data on non-existent socket: tcp_send_ready, 733a34de-e03d-4859-98e7-016e14f5c97b
stack traceback:
	[C]: in function 'error'
	[string "socket"]:205: in upvalue 'socket_receive'
	[string "socket"]:1461: in field 'select'
	[string "cosock"]:303: in field 'run'
	[string "st.driver"]:745: in method 'run'
	[string "init.lua"]:445: in main chunk

If data is received on a nonexistent socket, I would think it should not cause a fatal error, but rather should just be ignored.

Hey, @TAustin

Thanks for highlighting this issue!

To have a reference on the configuration of the request, can you please provide the implementation snippet of the socket.http module?

Hi, @TAustin.
About your comment here:

Did you share with Erick the implementation snippet as he requested in the post above?

I don’t think I ever did! But then again I don’t know what he’s wanting… this?

local cosock = require "cosock"
local socket = require "cosock.socket"

The error happens randomly and no way for me to tie it to a particular line in my code. (as I recall, line 445 is the driver:run() method

Missed the http module; I used to use this:

local http = cosock.asyncify "socket.http"

but have since switched to the more conventional:

local http = require "socket.http"

And I set a 3 second timeout on the socket:

http.TIMEOUT = 3

So, it doesn’t happen all the time? Perhaps you can share the code by sending us an email to build@smartthings.com so we can check it. The engineering team also needs a reference to see if the errors are related.
About the release of the 0.41 version, there’s no ETA yet.

No, this one is quite random and I have no way to consistently recreate it. I’ve seen it happen some time after an http request times out because the receiver isn’t responding. It most likely seems to happen when data is received after a timeout and after the http socket has been closed. If that happens, the data should be ignored rather than throwing a fatal error and stopping the driver. No matter what the cause, the engineering team should look at the code that is throwing this error and simply handle the case better by just throwing away the data and showing a warning message.

This is a good reference to check the issue. Ok, I’ll try to replicate it but I’ll report it either way.
It would be very helpful that you shared with me more details (over DM for security) like driver Id and the last timestamp you saw the error.

OK, next time I see it I’ll provide more info if I can. I have other people testing my Roku driver, and this is one of the reasons why they are finding that it keeps hanging up. (this, and the other socket bug that Eric said would be fixed). Because of these two socket-related bugs, I’m having to suspend work on on my Roku driver until these problems are fixed, because they make LAN drivers too unreliable for general use right now.

Thanks for sharing this, I’ll add it to the report I made and I’ll let you know their feedback :smiley: