emit initial data to other event after "on_connect" in AsyncNamespace

[SebBanDev]

I have an AsyncNamespace in which I want to send some initial data to some event on each connect:

    async def on_connect(self, sid: str, environ: dict, auth: dict):
        data = self.service.get_statistics()
        await self.emit("new-data", to=sid, data=data)
        logger.success("Client {} successfully initialized", sid)

However it seems that then the data is emitted to the new-data event before the server approves the client connection.
In other words, if I got it right, the data is sent to the event and the client in some cases won't receive it because the connect packet was not sent yet.
https://github.com/miguelgrinberg/python-socketio/blob/main/src/socketio/asyncio_server.py#L476-L477

This causes no Issue together with our Frontend socketio client, but if I use firecamp to test the namespace, the connection is not established after the data is emitted, so it does not reach the client.

A workaround that works fine is to force the emit to be called in the next loop after the connect is done:

loop = asyncio.get_running_loop()
loop.call_soon(lambda: asyncio.create_task(self.emit(...)))

But I have a feeling there is a better/cleaner way to do this somehow?

The only thing I found in the documentation is:
https://python-socketio.readthedocs.io/en/latest/server.html#event-callbacks
so to add a callback that should be executed only after the on_connect somehow. But I have no idea how that would look in the code (or if this is the right idea in the first place)

[miguelgrinberg]

You are correct in your observations. Emitting from the connect handler is not a great idea. The connect handler is supposed to be used to approve or reject connections, because the connection is only fully established once the connect handler exits. Some Socket.IO clients are able to receive emits from the connect handlers, others cannot.

The always_connect option (docs) is an option that you have if you want to emit in the connect handler without problems. With this option, the server accepts the connection before invoking the connect handler, so emits fully work. If you then decide to reject the connection, a disconnect is issued instead of the normal rejection packet, which would not work after the connection was accepted.