Is there a major design flaw in the websockets client api, or am i missing something? you can call `...

# ktor

[thana]

Is there a major design flaw in the websockets client api, or am i missing something?
you can call receiveDeserialized on the DefaultClientWebSocketSession but sooner or later this will inevitably result in an exception: as soon a Ping or a Close frame arrives this fails.
Wouldn;t you actually need something like frame.readDeserialiing() or similar, so you could write something like

for(frame in incoming){ 
  when(frame.frameType)  {
   FrameType.TEXT -> frame.readDeserialzied()
   FrameType.CLOSE -> return;
}
}

?

[e5l]

Hi @thana, it’s not expected to receive PING or Close in the default client session. They are handled automatically

[thana]

Hm ok. But i always get this exception in the console Converter doesn't support frame type CLOSE

[e5l]

That’s strange, could you log an issue with reproducer? I will take a look

[thana]

maybe i'm misinterepting the situation because i wrote while(true){receiveDeserialized()} and true is jjust a bad choice for rhe loop 😄

[e5l]

Thats fine. The CLOSE frames should be filtered out any way

[thana]

what would be the expected outcome when reading from a closed websocket session in an infinite loop? 🤔

[Aleksei Tirman [JB]]

You are right about receiveDeserialized in a way that it shouldn’t receive a frame, otherwise responsibilities for receiving and deserialization are mixed in this method and that leads to the problem you described.