This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-09-28
Channels
- # babashka (48)
- # babashka-sci-dev (7)
- # beginners (123)
- # calva (32)
- # cider (5)
- # clara (20)
- # clj-kondo (3)
- # cljdoc (2)
- # cljs-dev (1)
- # clojure (113)
- # clojure-dev (5)
- # clojure-europe (65)
- # clojure-norway (23)
- # clojure-spec (4)
- # clojure-uk (4)
- # clojurescript (33)
- # cursive (3)
- # datalevin (39)
- # datomic (2)
- # emacs (14)
- # events (1)
- # fulcro (10)
- # graphql (5)
- # humbleui (2)
- # integrant (4)
- # introduce-yourself (3)
- # jobs (1)
- # jobs-discuss (11)
- # kaocha (26)
- # leiningen (6)
- # malli (24)
- # nbb (2)
- # off-topic (69)
- # pathom (77)
- # podcasts-discuss (2)
- # reitit (8)
- # remote-jobs (2)
- # sci (17)
- # scittle (8)
- # squint (1)
- # xtdb (43)
I have a bug in my routing and/or reports that happens intermittently. I have a report with an on-select-row
that routes to another report. Sometimes it works, but other times it just hangs there. The log is a little verbose and indicates some timeouts, but increasing the :error-timeout
doesn't seem to help and the Inspect network tab isn't showing anything taking very long. Is there anything else in this log excerpt (in thread) that sticks out as the potential cause?
The thing that moves a router from pending to routed is a call to target-ready. That call isn’t happening, which is leading to the failed state. The default macro calls target ready after starting the new report. I’ve never had that fail, but if starting the report threw an exception then it would never route.
that’s the implementation of the routing will-enter handler for things generated by defsc-report
Hmm, I think the issue here is that report-will-enter
calls start-report!
, which in turn tries to trigger :event/resume
as long as there is any ::uism/active-state
. Since :will-enter
can be called multiple times at the start of route resolution, the first call can put the report in :state/loading
and a subsequent call will see that it's got an active-state
and will try to trigger :event/resume
, for which there is no handler. I believe this is what leads to this error:
> UNEXPECTED EVENT: Did not find a way to handle event :event/resume in the current active state: :state/loading See ...
Does this seem like a bug to you, @U0CKQ19AQ?
https://github.com/fulcrologic/fulcro-rad/blob/2e668d5ce271299c5efc4f2748a3b021534d5a6a/src/main/com/fulcrologic/rad/report.cljc#L529-L532
> The thing that moves a router from pending to routed is a call to target-ready.
I think something different is happening here. I don't route directly to a report because I start+render the report myself in a defsc. Here's a diagram of my layout. It looks like the TabRouter
is doing fine, but the MainRouter
doesn't get updated as it should. Is there anything obvious that could cause that which I'm missing?
And it doesn't happen every time. Maybe 1 of 5 or so... which makes it harder to track down.
sounds like a problem in your logic for the target of the MainRouter…RepoProfile isn’t calling target-ready correctly, or perhaps your Tab1-Report wrapper isn’t doing the start of the state machine for the report correctly. Impossible to tell without looking over all of the code.
I think I've finally gotten to the bottom of it. The RepoProfile uses Tab1 as the first route. In RP's :will-enter, I was calling start-report!
on Tab1-Report
. However, I was routing to Tab1
(leaf node), which also called start-report!
on the same Tab1-Report
. I guess this was creating some conflicting ops where the timing of the load played a factor, leading to the intermittent failures. The solution was to only call start-report
in RP's :will-enter and to do a dr/route-immediate
in the tab's :will-enter.
Thank you for the suggestions, @U0CKQ19AQ. Every time some issue like this kicks my ass I always end up learning a bunch. The fact that Fulcro only has so much surface area makes me optimistic that eventually I'll have it covered.
I suppose there is no way to detect conflicting simultaneous loads like this beyond debugging the resulting errors?