Reconnect and middleware firing order with non-default namespaces

[perrin4869]

I just finished changing the default namespace / in my server to another namespace, /main and I stumbled upon this problem:

io.use(() => console.log('default namespace');
io.of('/main').use(() => console.log('main namespace');

// client
client.on('reconnect', () => console.log('reconnected');

Now, if a reconnect happens, the above will happen in the following order:

default namespace
reconnected
main namespace

This is a problem because I need to do some authentication before a user can be reconnected on the main namespace. I think that the ideal output would be:

main namespace
reconnected

Without passing through the default namespace at all, or at least firing reconnect after finishing processing the middlewares of the main namespace.

[nkzawa]

reconnect event is an event of Manager (see https://github.com/socketio/socket.io-client#events), so I think the order actually makes sense. Maybe you'd want to use connect event instead of reconnect? connect is emitted on reconnection as well.

[perrin4869]

I see! Well, for once, the behavior of the / namespace would be inconsistent with other namespaces in this case, since it's the only namespace whose middlewares are fired before the reconnect event.

Second, I think this behavior might be counter intuitive to the end users. Why would the reconnect event work while the connect event fails? How can you distinguish between a reconnect and a connect event? Also, personally, I'd expect that if upon an attempt to reconnect, there was an authentication error, then the reconnect event won't fire since reconnection failed because of invalid credentials.

I think that the root of the problem are the inconsistencies between the / namespace and the rest of the namespaces, as discussed in #2124

[nkzawa]

the behavior of the / namespace would be inconsistent with other namespaces in this case, since it's the only namespace whose middlewares are fired before the reconnect event.

Actually, this is by design. I also don't know the details, but you'd be able to set "global" middleware to / and would set scoped one to /namespace.

Why would the reconnect event work while the connect event fails?

That can happen because reconnect is per connection(Manager), while connect is per namespace(Socket), like internal connection was established but access to a namespace could be rejected. I think this makes sense, but I agree this is not so intuitive.

[perrin4869]

I'm not sure how useful this reconnect event is in this case, to be honest... if this is the way it'll remain, however, I think it needs heavy clarification in the documentation

[perrin4869]

Maybe separating the Manager reconnect and Socket reconnect would be the best solution, as they are rather different functionalities, conceptually speaking, as you have explained. Manager reconnect would remain as is, and would remain available to users (although I have a hard time thinking of a use case for this event), while the socket reconnect would work as expected.

In the documentation too, both events are separated, and their differences would be pointed out:

https://github.com/socketio/socket.io-client#events
https://github.com/socketio/socket.io-client#events-1

[perrin4869]

I think that the point I'm trying to make is, as an end user, I don't really care if the manager can or can't reconnect to the webserver, the only thing I care about is whether or not the socket can reconnect to the namespace

[oniono]

NAVER - http://www.naver.com/

[email protected] 님께 보내신 메일 <Re: [socket.io] Reconnect and middleware firing order with non-default namespaces (#2343)> 이 다음과 같은 이유로 전송 실패했습니다.

---

받는 사람이 회원님의 메일을 수신차단 하였습니다.

---

[perrin4869]

Closing this, since this is an issue of socket.io-client