I'm having a hard time wrapping @huggingface/transformers.js as a cljs lib. I think it's doing some squirrely async/await stuff on initialization and so calling pipeline and .thening isn't working - though my js foo is not too current with that stuff - I could be doing it wrong. Any recommendations? https://huggingface.co/docs/transformers.js/tutorials/vanilla-js
(js-await [detector (pipeline "object-detection" "Xenova/detr-resnet-50")]
(use detector))https://clojureverse.org/t/promise-handling-in-cljs-using-js-await/8998
if that is what you are asking about
hmm, I did try that originally but it didn't work. Lemme confirm...
Hi, I have a web app with a shared worker that keeps a websocket connection to the server. This app misses when the csrf token expires. I would like to tell this apart from the server being down or connectivity lost, which calls for retry, while 403 calls for getting a new token. The handlers on the websocket like on-error, on-close etc. and socket state have timestamps but I can not get the information from them that the csrf token expired (403). I do not have production error messages, since remote logging requires the csrf token too. However this test at the repl
(try
(let [WebSocket (gobj/get goog/global "WebSocket" nil)]
(WebSocket. ""))
(catch :default t (println "caught"))
(finally (println "nothing to catch")))
prints
14:30:05.303 core.cljs:200 nothing to catch
14:30:05.351 VM1006:2 WebSocket connection to '' failed: Error during WebSocket handshake: Unexpected response code: 403
to the console and returns an unconnected WebSocket.
Is this even catchable? If yes, any ideas how? Does catching this only work on first connect or would it catch too when the worker returns from sleep?
Or do I need an "out of band" test, that uses a separate fetch/xhr request to test the validity of the csrf token after a timeout non-connectivity?
Does anyone have pointers? This is hard to google.websocket upgrades must always upgrade, they may not return other status codes (403). well they can but the browser does not any expose API to see this in the websocket side of things.
after upgrading you can close the websocket server side and provide a code/reason which the client can access in the close event https://developer.mozilla.org/en-US/docs/Web/API/WebSocket/close_event
but even that is often not passed through properly in browsers
I usually have the server send a welcome or denied message as the very first message
so instead of solving that over status codes solve it over a message, with the very single reason being that the client can handle that properly 😛
Wow!! Thank you Thomas!