Session expiry isn't forwarded to the client

[roosterfish]

When the join session expires, the server hangs up on the client (websocket) and logs the following error Session timeout exceeded.
This exact error should also be visible on the client side. But instead the client seems to see only ⨯ Error: Failed to read join confirmation: websocket: close 1006 (abnormal closure): unexpected EOF which is misleading and indicates we don't properly handle close on the websocket client side.

[shardool-patil]

Hi @roosterfish I'd like to work on this issue if anyone hasn't started working otherwise you can point to any other issue where help is needed, I'll be happy to help.

[roosterfish]

@shardool-patil thanks for your interest in this. I have assigned it to you.

[shardool-patil]

@roosterfish I took a look at the issue and code and this is what i think

Root Cause

• WriteClose is blocked by context cancellation: When the session expires, gwCtx is canceled with the error cause ("Session timeout exceeded"). The cleanup goroutine in client/websocket.go invokes gw.WriteClose(...). However, WriteClose delegates to w.Write(), which checks if w.ctx.Err() != nil and immediately returns without sending the ControlClose frame over the wire. The socket is then abruptly closed via gw.conn.Close(), triggering the client-side close 1006 (abnormal closure): unexpected EOF.
• Channel closure handling in ReceiveWithContext: ReceiveWithContext does not verify if the reader channel was closed (bytes, ok := <-w.Receive()). When the connection drops, it receives nil bytes and fails during JSON unmarshaling instead of returning context.Cause(w.ctx).

Proposed Fix

• Direct socket write in WriteClose (client/websocket.go): Acquire w.writeLock and write ControlClose directly via w.conn.WriteJSON(...) so the message is transmitted even after w.ctx has been canceled.
• Guard closed reader channel in ReceiveWithContext: Check the ok flag on <-w.Receive() and return context.Cause(w.ctx) when the channel closes.
• Sanitize ControlClose parsing: Verify controlClose.ControlMessage != "" in the reader loop to prevent empty payloads from being treated as close frames.

just wanted to make sure before opening a pr.

[roosterfish]

Make sure to check whether or not the cause ("Session timeout exceeded") is already present on the joiners side. You can check in the daemon logs for a message which might contain this or an equivalent string.
It might be the problem is that the joiner's daemon doesn't properly push the cause to the client running microcloud join (over the websocket).

In any case please also extend the test suite and add another check that will cause the session to expire so you can check if a joiner that already reached out to the initiator sees the "Session timeout exceeded" error.
For this you can use a rather short microcloud init --session-timeout to let the test return early.