Close received after close

[magnars]

Hi!

When my server closes the websocket channel, the client throws an error:

WebSocket connection to 'ws://localhost:9009/gateways/0200000100000205/progress.ws' failed: Close received after close

and the ws-channel returns {:message nil}.

I've boiled the server code down to:

(with-channel request ws-ch
    {:format :json-kw}
    (go
      (>! ws-ch "testing")
      (<! (timeout 1000))
      (close! ws-ch)))

On the client I then first get {:message "testing"} and after 1 second, I get the above error, then {:message nil}.

My client code looks like this pared down:

(defn connect [uri]
  (let [c (chan)]
    (go
      (let [{:keys [ws-channel error]} (<! (ws-ch (str "ws://" (.-host js/location) uri) {:format :json}))]
        (when-not error
          (loop []
            (let [v (<! ws-channel)]
              (prn v)
              (if-let [{:keys [message error]} v]
                (cond
                  error (do
                          (prn error)
                          (recur))
                  message (do
                            (>! c message)
                            (recur))
                  :else (close! c))
                (close! c)))))))
    c))

Any idea what's going on?

Thanks!

[jarohen]

Hi Magnar - it's been a while since I've looked at this code, I'm afraid - will take a look!

James

[magnars]

Thanks James. Let me know if I can help with more debugging information in some way!

[jarohen]

I've managed to repro this pretty quickly - thanks for the small test case :)

Unfortunately I've now spent a fair bit of time debugging to no avail - from what I can tell it's the server side that's causing it, yet Chord (and http-kit within it) are only sending one 'close' to the websocket.

Will keep digging

[jarohen]

Ah. https://code.google.com/p/chromium/issues/detail?id=372776 suggests it might be an issue with Chrome devtools, and I can't seem to repro in Firefox. Is it the same for you?

[magnars]

Thanks for digging into this, much appreciated. Seems like it is indeed Chrome dev tools, I cannot reproduce this in Firefox. Sorry for the wild goose chase!

[jarohen]

No worries! Tbh, it's made me re-visit Chord, which is a good thing - I haven't had chance to give it much love recently!

James

[magnars]

Glad to hear it was of some use. :-)

There is one interesting thing to comment on: I do get that {:message nil}, so to work around this bug in Chrome, I have to add a conditional checking for an event that should never happen in core.async.

[jarohen]

Ah, that does seem like a bug on Chord's side!

[jarohen]

Have pushed 0.7.0-SNAPSHOT with a fix for this issue - it now returns 'nil', so you can tell when the channel's closed.

Let me know if this fixes your issue?

Cheers!

[magnars]

Wow, this is pretty weird. I am thankfully no longer getting the {:message nil} oddballs, but I get nil several times.

I can't explain it, really - there should be no recurring, so I can't really explain how it reaches the print statement more than once. Maybe I've done something crazy. I wouldn't spend any more time on it unless other people come crashing in here with similar reports. :-)

[magnars]

To be clear, the "up-to-date" message is sent once from the server, and then it closes the channel.

[magnars]

I realized now that my code is trying to re-open the websocket for a while after it closes, so that explains the weirdness in my screenshot. Disregard. :blush: The 0.7.0-SNAPSHOT seems to have worked as intended.

[jarohen]

:) thanks!