sio.disconnect() will connect after a connection drop

[ghost]

Describe the bug
sio.disconnect() will connect after a connection drop

To Reproduce
Steps to reproduce the behavior:

1. Connect to your backend
2. do the functions you want
3. once done, use sio.disconnect() and it will reconnect if you dropped connections

Expected behavior
should fully disconnect, not connect again

Logs

Emitting event "send_position_1" [/]
Received event "get_position_1" [/]
Engine.IO connection dropped
Connection failed, new attempt in 1.43 seconds
Engine.IO connection established
Namespace / is connected
Reconnection successful

Additional context
once connection dropped, and then using sio.disconnect(), it will reconnect after

[miguelgrinberg]

This is likely a problem in your application. Could you please share a simple client and server that reproduce this problem?

[ghost]

I dont have a simple example of it, as its a pygame app

but here is some of the code with most stuff cut out that isnt socketio related

def multiplayer():
    global paddle_a, paddle_b, ball, ball_dx, ball_dy, score
    initialize_game()
    sio.connect('https://ultimatepingpongsocket.xytriza.com')
    while True:
        if ball.left <= 0:
            if sio.connected:
                sio.disconnect()
            initialize_game()
            death_screen(score, 2)
        if ball.right >= 800:
            if sio.connected:
                sio.disconnect()
            initialize_game()
            death_screen(score, 2)

        keys = pygame.key.get_pressed()
        if keys[pygame.K_w] and paddle_a.top > 0:
            paddle_a.y -= 5
            if sio.connected:
                sio.emit('send_position_2', paddle_a.y)
        if keys[pygame.K_s] and paddle_a.bottom < 600:
            paddle_a.y += 5
            if sio.connected:
                sio.emit('send_position_2', paddle_a.y)

        pygame.display.flip()
        pygame.time.Clock().tick(60)

for some reason if i send too many updates to the server itll cause a freeze

[miguelgrinberg]

The logs do not show that you have initiated a disconnection, they show that the client lost the connection to the server, and for that reason it is attempting to reconnect. If you do not want reconnections to happen, you can disable it when you create the client object.

[ghost]

well i lost connection a bit before i died, and then disconnect didnt do anything

[ghost]

i do want reconnects tho, just not after sio.disconnect()

[miguelgrinberg]

Let me see if I understand. You got disconnected from the server, and while the client was in the process of reconnecting you called disconnect()? And your expectation is that this will stop the reconnection?

[vipcxj]

@miguelgrinberg Hi, How can I recognize whether the disconnect event is triggered by invoking disconnect method or a network issue in on callback? I think we should use another event (maybe called close) to represent disconnect triggered bt user manually disconnect. The socket.io official provide a reason as the argument of the callback, however according document, python-socketio use a none argument callback for disconnect event. I think the official approach is bizarre, but at least it offers a solution

[miguelgrinberg]

@vipcxj correct, the disconnect reason is not being exposed to the disconnect handler. I have never got around to expose that. Will think about how to best do this.

[ghost]

Let me see if I understand. You got disconnected from the server, and while the client was in the process of reconnecting you called disconnect()? And your expectation is that this will stop the reconnection?

yes this is correct, when dropping connection to the server, and then disconnect() it should cancel the reconnect, not continue it as its meant to be disconnected

[miguelgrinberg]

The thing is, calling disconnect when you are disconnected doesn't do anything, since you are already disconnected.

There is currently no way to interrupt a reconnect loop, but there are options to disable reconnects, or to indicate how many retries you want before giving up. I will consider adding a way to interrupt a reconnect loop in the future, but right now it is not possible.

[ghost]

it should cancel the reconnect.

[miguelgrinberg]

As I said, I will think about how to interrupt a reconnect loop.

[ghost]

ok👍

[blazing-gig]

I managed to achieve this by manually setting the _reconnect_abort event explicitly like so:

if self._sio_client.connected:
    await self._sio_client.disconnect()
    if self._sio_client._reconnect_abort:
        self._sio_client._reconnect_abort.set()

This seems to have worked.
@miguelgrinberg Could you pls comment on if this can serve as a potential workaround or even a fix ?

[ghost]

Sorry I haven’t checked GitHub, but when I lost connection and the player exits the menu (disconnects) it doesn’t disconnect is what I am trying to explain

…

On Tue, Jan 9, 2024 at 1:39 PM Aditya N ***@***.***> wrote: I managed to achieve this by manually setting the _reconnect_abort event explicitly like so: if self._sio_client.connected: await self._sio_client.disconnect() if self._sio_client._reconnect_abort: self._sio_client._reconnect_abort.set() This seems to have worked. @miguelgrinberg <https://github.com/miguelgrinberg> Could you pls comment on if this can serve as a potential workaround or even a fix ? — Reply to this email directly, view it on GitHub <#1277 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BCRDSMTJ345MSRZKCYQ4LYDYNWTIDAVCNFSM6AAAAAA7D62YYGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBTG42TSMBZHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[ghost]

Also I’m not using classes so this isn’t helpful to me

…

On Tue, Jan 9, 2024 at 1:40 PM Xytriza ***@***.***> wrote: Sorry I haven’t checked GitHub, but when I lost connection and the player exits the menu (disconnects) it doesn’t disconnect is what I am trying to explain On Tue, Jan 9, 2024 at 1:39 PM Aditya N ***@***.***> wrote: > I managed to achieve this by manually setting the _reconnect_abort event > explicitly like so: > > if self._sio_client.connected: > await self._sio_client.disconnect() > if self._sio_client._reconnect_abort: > self._sio_client._reconnect_abort.set() > > This seems to have worked. > @miguelgrinberg <https://github.com/miguelgrinberg> Could you pls > comment on if this can serve as a potential workaround or even a fix ? > > — > Reply to this email directly, view it on GitHub > <#1277 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/BCRDSMTJ345MSRZKCYQ4LYDYNWTIDAVCNFSM6AAAAAA7D62YYGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBTG42TSMBZHE> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

[blazing-gig]

@Xytriza You can get rid of the self if you aren't using classes. sio_client from my example above, is just an instance of socketio.AsyncClient.

[ghost]

ok

[miguelgrinberg]

I managed to achieve this by manually setting the _reconnect_abort event explicitly like so:

if self._sio_client.connected:
    await self._sio_client.disconnect()
    if self._sio_client._reconnect_abort:
        self._sio_client._reconnect_abort.set()

This seems to have worked. @miguelgrinberg Could you pls comment on if this can serve as a potential workaround or even a fix ?

This is not something that I would recommend, because you are using private attributes that are not guaranteed to be preserved in future releases, but as a temporary workaround it may be okay. You should probably wait for the reconnect task to end after signaling it to exit.

[blazing-gig]

@miguelgrinberg Right. So I believe just adding this line should do:

if self._sio_client.connected:
    await self._sio_client.disconnect()
    if self._sio_client._reconnect_abort:
        self._sio_client._reconnect_abort.set()
        await self._sio_client._reconnect_task # Per your suggestion

[miguelgrinberg]

Sure. As I said above though, I cannot guarantee that this will continue to work in future versions, since you are accessing privates/internals of the library.