Hi all, is it possible to detect if a websocket session was closed by the client? I'm getting some w...

# ktor

[Vinicius Carvalho]

Hi all, is it possible to detect if a websocket session was closed by the client? I'm getting some weird errors when a client closes the connection by leaving the page.

[Deactivated User]

What kind of error do you have?

[Vinicius Carvalho]

It's not related to ktor actually, it's due a channel that I create. In order to avoid having Websocket interfaces (such as Frame.Text) on my business classes I connected both using a channel

[Vinicius Carvalho]

webSocket("/arenas") {
                val channel = Channel<Status>()

                frameUpdater.subscribe(channel)
                for(status in channel){
                    outgoing.send(Frame.Text("timestamp: $status"))
                }
            }

[Vinicius Carvalho]

it works fine when connections are alive, the frameUpdater has a suspended function that keeps producing data to the channel

[Deactivated User]

And what happens when the use closes the tab?

[Vinicius Carvalho]

but when the connection is closed, I get an error that the channel is no longer opened, and it's not like I'm getting the error on the producer side, it's actually at the for loop

[Deactivated User]

that makes sense, probably it happens on the outgoing.send method

[Deactivated User]

I guess that’s the expected behaviour, right?

[Vinicius Carvalho]

same error at close

[Vinicius Carvalho]

I guess if the error was in the send, that's what trigged my question. Error is on the receive side, which is odd. I should have better treatment for the producing side checking if the channel is closed and if it is remove it from the produce operation

[Deactivated User]

I guess you should wrap the function after subscribe in a try..catch + finally, ignore expected errors for connection close, and unsubscribe on the finally block
?

[Deactivated User]

the producer is not bound to that websocket as far as I understand from that snippet

[Deactivated User]

as I understand you have a producer outside not bound to any websocket, and then you are doing a fanout to each websocket with the produced information

[Deactivated User]

is that right?

[Vinicius Carvalho]

that's correct

[Vinicius Carvalho]

so it really seems that because the outgoing channel is closed the exception was being bubbled up, a bit weird where the stacktrace reports it though

[Vinicius Carvalho]

Thanks for the help 🙂

[Deactivated User]

didn’t checked the stacktrace, though without asynchronous stacktraces enabled things are usually a bit weird, yes 🙂 so maybe it had sense somehow, but was far from obvious