call() method times out when connection/namespace is disconnected before result is sent.

[kristjanvalur]

Describe the bug
This may or may not be a bug. Perhaps it is "as designed", In which case, please feel free to ignore :)

The following interaction has been observed using the AsyncClient:

1. Client connects to a namespace.
2. Client gets an on_connect event. The handler makes a call("hello") to the server and waits for a result
3. Server gets on_hello event.
4. server both emits a emit("failure") message to the client and returns "failure" (*)
5. client receives on_failure event and performs an sio.disconnect() call, disconnecting all namespaces.
6. Meanwhile step 2, from a above, is still waiting for the result from step 4.
7. After 60 seconds, a TimeoutError is raised.

Expected behavior
I would expect step 7 above to result in an immediate "Client is disconnect" exception to be raised on the connection.

Additional context

(*) the reason I'm both emitting an event and returning a value, is that I'm trying to migrate from naked events into an rpc-like architecture. Older clients will be listening for the "failure" event, newer clients will be waiting for a response from the call()

[miguelgrinberg]

Yeah, this is really working in the way it was designed. The call() method just waits for the callback to arrive. If you disconnect, then the callback packet will never arrive. The correct response in this case is to issue the timeout when the 60 seconds (or whatever timeout you specified) have passed.

[kristjanvalur]

I get it, except that the documentation doesn't mentioned that the 'call' is really implemented by waiting for a callback, a kind of a special event. If there is no concept of "aborted callback" in the JS version, then adding support to notify cancelled callbacks in the python version might be too much trouble If I were to do that, I'd keep a weakset of pending notifications attached to the connection. and flush them once it went away :) We implemented such stuff a number of times when doing async IO for stackless python back in the day. þri., 26. okt. 2021 kl. 11:40 skrifaði Miguel Grinberg < ***@***.***>:

…

Yeah, this is really working in the way it was designed. The call() method just waits for the callback to arrive. If you disconnect, then the callback packet will never arrive. The correct response in this case is to issue the timeout when the 60 seconds (or whatever timeout you specified) have passed. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#813 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABN3FR464NTCWZ7GKDTXFM3UI2OVXANCNFSM5GXPVK2Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[miguelgrinberg]

It is certainly possible to implement what you are suggesting, but I see this as a rare corner case. I would be making the code more complex and harder to maintain and test just to support a workflow that 99.9% of users will never encounter, and for the 0.1% that do, nothing is really broken and the function still works as advertised.

If you'd like to propose an improvement to the documentation I'm open to that.

[kristjanvalur]

I'll try to think of something. This is the only function in the api that isn't a simple event handler and does not respond to discrete events. Execution logic effectively blocks and thus it cannot respond to asynchronous state changes. Usually blocking functions (even if virtually blocking) get the chance to respond to unexpected state changes by means of a signal, (EAGAIN, ECONNRESET, etc in case of files, sockets): This includes any sort of communication failure out of the control of the program, such as network issues, server dying, and so on. Anyway, something along the following: Note: This method relies on the _callback_ mechanism described for `emit()` to return the value. In case the connection is disconnected, or there is a server error, the function will eventually time out. Cheers! þri., 26. okt. 2021 kl. 13:53 skrifaði Miguel Grinberg < ***@***.***>:

…

It is certainly possible to implement what you are suggesting, but I see this as a rare corner case. I would be making the code more complex and harder to maintain and test just to support a workflow that 99.9% of users will never encounter, and for the 0.01% that do, nothing is really broken and the function still works as advertised. If you'd like to propose an improvement to the documentation I'm open to that. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#813 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABN3FRY5ZLX4YV7G6KW4SATUI26INANCNFSM5GXPVK2Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.