This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-01-05
Channels
- # announcements (1)
- # babashka (61)
- # babashka-sci-dev (1)
- # beginners (54)
- # biff (17)
- # cider (4)
- # circleci (1)
- # clj-commons (39)
- # clj-kondo (26)
- # cljdoc (40)
- # clojure (41)
- # clojure-europe (32)
- # clojure-norway (4)
- # clojure-portugal (1)
- # clojure-uk (2)
- # clojurescript (59)
- # clr (69)
- # conjure (7)
- # cursive (22)
- # data-science (16)
- # datalevin (1)
- # datomic (19)
- # docker (31)
- # funcool (1)
- # honeysql (6)
- # hoplon (1)
- # hyperfiddle (41)
- # introduce-yourself (1)
- # juxt (2)
- # leiningen (5)
- # nbb (14)
- # nextjournal (38)
- # off-topic (47)
- # polylith (2)
- # rdf (5)
- # re-frame (4)
- # reitit (27)
- # releases (6)
- # scittle (10)
- # shadow-cljs (24)
- # sql (11)
- # squint (1)
- # tools-build (33)
- # tree-sitter (4)
- # vim (39)
Note that if the server has redeployed and the client connects to a newer server version, the reconnection will occur despite the code version mismatch, and this is undefined behavior
We opened a ticket to deal with this, likely by validating a hash of the program or something like that and asking the user to refresh the page to get the new version. Transparently upgrading through continuous deployments is possible long term but not a priority
let me know, i wasn't able to get my phone to sleep to repro your actual issue (for me on mobile safari the websocket stayed alive no matter what i did to my phone, just throttled)
the app will reboot. We did implement resync but in testing found a design flaw in Photon, we intend to address it in the next photon iteration (starting now)
you'll need to put your state in durable atoms, so backed by localstorage, url, database etc
once there’s an error this change seems to land in a loop where the frontend keeps restarting and retriggering the error
Leo pushed fixes to this
I know what causes the error in this case. the server is actually fine. it’s one p/server expression calling a function in a p/defn view that errors on certain inputs. it seems that view could error in isolation without blowing up the rest of the stack.
ok let me think about that
do you have a try/catch everything at the entry point?
yes
(p/defn Main []
(try
(let [!path (m/mbx)
route (decode-path (router/path !path) hf/read-edn-str)]
(binding [router/Link (router/->Link. !path encode-path)
dom/node (dom/by-id "root")]
(p/server
(views/App. route))))
(catch Pending _)
(catch Cancelled e (throw e))
(catch :default err
(js/console.error (str (ex-message err) "\n\n" (dbg/stack-trace p/trace)) err))))
(def ^:export main
#?(:cljs
(p/boot
(Main.))))
you’re throwing cancelled ?
oh here
I basically copied https://github.com/hyperfiddle/photon/blob/571e6125f402d19f46ed875ef4497f1045ba2029/src-dev/user_main.cljc
To repro the issue, i tried
(ui/button {::ui/click-event (p/fn [e]
(p/server
((identity nil)) ; crash
(swap! !x not)))}
"toggle client/server")
but it doesn't disconnectwhat exception is being thrown in the view that is crashing the server reactor?
in my example i have a NPE on click via (p/server ((identity nil)))
i think we send a dummy RemoteError
I'm not sure what to try next to reproduce
this does repro for me https://clojurians.slack.com/archives/C7Q9GSHFV/p1673302314951079?thread_ts=1672939429.797809&cid=C7Q9GSHFV
Following up in public after DMs,
this blows up: (comment (encode (Failure. (Remote.))))
at REPL from
is a stackoverflow
this seems obviously an older regression which is getting in the way of understanding the NPE response
The stackoverflow is fixed
@denik let's recalibrate - what is the current status, does a NPE in userland cause undesired behavior now that the failure serialization error is fixed?