Clojurians Log v2

Hmm

very very strange

subscribe uses socket behind the scenes

so if subscribe works, socket should work in the same way

if that error is happens is not because postal client

is because your handler returns a http response instead of doing the websocket handshake

There no other way to see a clear error because websocket impl in the browser just does that

@niwinz: Not sure why the server would be returning an http response instead of the websocket handshake. This is my route: [:any "postal" (pc/router #'handlers/postal-handler)] And an example handler:

(defmulti postal-handler
          (fn [ctx frame] (select-keys frame [:type :dest])))
(defmethod postal-handler {:type :subscribe
                           :dest :reports}
  [ctx frame]
  (letfn [(on-connect [{:keys [in out] :as context}]
            (println "connect")
            (go
              (>! out (pc/frame {:value "test"}))))]
    (pc/socket ctx on-connect)))

:S

Catacumba 0.10.0 does the same? Is for discard something that I have broken in the last release

due to memory leak fix on websocket engine

I'll try 0.10.0 right now

Getting the same error

Hmm ok, it is not related to bug fix

Can you paste the both lines you are using to connect to catacumba: the subscribe and the socket ?

(from cljs)

maybe the bi-directional socket does not reaches that handler

and reaches other...

[instream outbus] (pc/socket client :messages) and bus (pc/subscribe client :messages) where (def client (pc/client (str (.-origin js/location) "/postal")))

If you want use bi-directional sockets

you should change the {:type :subscribe with {:type :socket

the error surelly is hapens because me message arribes but it does not routes to appropiate handler

That did it :simple_smile: I didn't see that minor detail anywhere in the docs. Did I miss it?

Maybe the docs are wrong that is clearly possible

I think it's just missing that difference. Thanks for the help! :simple_smile:

You are welcome!

How do you guys do error handling with core.async channels with catacumba?

something along the lines of:

(go
      (let [groups (<! groups-chan)]
        (if (instance? Throwable groups)
          (throw groups)
          (ct/delegate {:groups groups}))))))

hi @mitchelkuijpers! In my code I try to isolate the logic and corresponding possible error raising code in separate functions and in catacumba handlers just use that functions and capture posible errors and return corresponding http request with error...

Aha that sounds reasonable, I don’t really see a generic solution to this problem. Maybe I should just use a promise

thnx @niwinz

But now I see that there no way to use the generic error handling mechanism that catacumba have... with async values

https://funcool.github.io/catacumba/latest/#error-handling

Ok no problem

This can be used with simple handlers. If simple handler raises an exception that error handler will be executed

Yes I know we use that

I think that this should work in the same way with async results

Maybe fun to know, we are currenlty running in production for about 3 months now with catacumba: https://marketplace.atlassian.com/plugins/nl.avisi.jira.plugins.relations-for-jira/cloud/overview

Yes maybe it should but currently it doesn’t right?

@mitchelkuijpers: thanks for sharing! It is awesome!

no, at this moment it does not works, at least with core.async no...

It should work with manifold and with promesa (completable future)

Ow awesome

Thank you sir

\o/