[BUG] JS client does not receive messages if both polling ad websocket transports are configured

[mabi]

Description

Using JS client Socket.IO v4.8.3
const socket = io('https://myserver:8443/terminal');
without specifying transports, so by default:
Default value: ["polling", "websocket", "webtransport"]
or specifying { transports: ["polling", "websocket"] }
in the server side logs I see the client connection event and then after the first message sent from the server I see the disconnect event.
On the client side the connection is reported established.
No message is received.
Messages sent from the client are logged in the websocket but not received from the server.

If I enable just one transport at a time i.e. :
const socket = io('https://myserver:8443/terminal', { transports: ["websocket"] });
or
const socket = io('https://myserver:8443/terminal', { transports: ["polling"] });
[EDIT] everything works receiving messages works, sending messages does not work for websocket, works with polling

Steps to Reproduce

1. connect using a JS browser client to a namespace using defaults
2. from the server send a message to the namespace

Expected Behavior

Messages are received

Actual Behavior

No message received

Environment

• Java Version: 17
• OS: Windows
• Netty-SocketIO Version: 4.0.0-alpha commit fddd5d1
• Module: core/spring

Code Example

const socket = io('https://myserver:8443/terminal');

Logs/Stack Trace

N/A

Additional Context

WSS is used

[NeatGuyCoding]

Found the cause, will be fixed today, thanks for the issues

[NeatGuyCoding]

When running over TLS/WSS, inbound Socket.IO payloads were forwarded using pipeline.fireChannelRead(...), which re-enters the pipeline from the head. That caused non-ByteBuf messages (our PacketsMessage) to traverse SslHandler / codec handlers again. While Netty typically forwards unknown message types, this interacts badly with SslHandler / ByteToMessageDecoder state, and in practice led to a situation where encrypted application_data records were received pre-SSL but the corresponding plaintext was intermittently not produced, so the server never decoded the subsequent Socket.IO event/ack.

[ulyssedu45]

hello, when you think fix can be release ?

[NeatGuyCoding]

https://github.com/socketio4j/netty-socketio/releases/tag/v4.0.0-beta
@mabi @ulyssedu45