Hi, @tony.kay — I spent some time yesterday getting a CLJ version of com.example.membrane-ui.http-remote running, and got some df/load! running. This morning, I actually got a RAD report to load — a frankenstein app that cannot shamble on its own, lots of REPL commands required to get it running, but can render something! But there’s some machinery that is stuck — the report UISM is stuck in loading state (although one time I saw it stuck in gathering-parameters state). I think the reason is that there are 13 transactions stuck in the the com.fulcrologic.fulcro.algorithms.tx-processing queue. (Screenshot from Portal attached.) Can you speculate on what might be happening? (I noticed that 50% of the df/load! operations don’t actually result in the network message being processed — repeating the load will eventually trigger all the processing to happen. I even tried manually calling process-queue!, but I did this without trying to understand how it all works.) PS: If I can get the RAD report to load, I’m sure the report to render — I just need current-rows to be populated. 🙂 🎉. (Screenshot of the row count attached, too. Currently showing 0. 🙂 cc @smith.adriane

My guess is that your new remote doesn’t handle exceptions/errors properly. You MUST always tell Fulcro that the network request is done, even if it fails. There’s an ok-handler and an error-handler. The queue processes one thing at a time by default, and will not continue until it knows the state of the one that is “current”

The :parallel? true flag on load bypasses the queue, which makes it harder to reason about an app, but allows parallel network requests (which also loses ordering)

Fulcro is responsible for moving things along. There should be no bugs there. It has to be your remote not catching something or not reporting a non-200 result.

Okay, thanks, @tony.kay! I’m getting closer, I think — your speculation is right on. I definitely am very suspicious of that region of code that I hacked on — I may just take out the asynchronous clj-http call, just to try to simplify some things. And get a test written to confirm that active-queue is eventually emptied.

PS: Merely switching to synchronous tx makes all the networking work! (I’m sure there’s problems in the code I wrote in http area, but good enough for now.). Hanging in membrane code somewhere. Getting close! 🙂