clojurescript

john 2024-12-27T07:03:09.253489Z

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

thheller 2024-12-27T07:57:34.176029Z

(js-await [detector (pipeline "object-detection" "Xenova/detr-resnet-50")]
  (use detector))

thheller 2024-12-27T07:58:13.640929Z

if that is what you are asking about

john 2024-12-27T14:06:49.864279Z

hmm, I did try that originally but it didn't work. Lemme confirm...

magra 2024-12-27T08:13:03.518709Z

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.

thheller 2024-12-27T08:15:43.116319Z

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.

thheller 2024-12-27T08:16:35.357539Z

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

thheller 2024-12-27T08:16:48.246319Z

but even that is often not passed through properly in browsers

thheller 2024-12-27T08:17:52.714369Z

I usually have the server send a welcome or denied message as the very first message

thheller 2024-12-27T08:18:15.998899Z

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 😛

magra 2024-12-27T08:20:22.432029Z

Wow!! Thank you Thomas!