Clojurians Log v2

I tried all the way down to Fulcro 3.2.17 and Pathom 2.2.0 - 2.2.30 and still could not make it work properly. I'm running out of ideas here.

what is nstate/remove-entity? does that happen even if the server errors, like if the remote mutation doesn't exist? what happens if you have more notes in the state map, only the id you try to delete becomes nil?

the server return value is probably a red herring. it shouldn't do anything to client state unless explicitly merged

Yes but from what's been said the server return is causing the problem. So there is some unintentional merging happening. 'shouldn't', yet is. But if your action did nothing you wouldn't get the problem. So the action prepares the state for a strange mutation return to cause the problem. You could put print statements in the fulcro source.

There's a function called integrate-mutation-return-value!. Surely the culprit! Maybe just have it do nothing on your own version of the fulcro library.

In com.fulcrologic.fulcro.mutations .

I wouldn't be doing anything with server errors while you investigate this problem.

yeah, the swap! in that integrate mutation function only runs if there's wasn't a remote-error?, so if it has a different behavior on error then it's probably something going on there and I'd add logging to that function

@kevin842 > what is nstate/remove-entity? https://cljdoc.org/d/com.fulcrologic/fulcro/3.4.3/api/com.fulcrologic.fulcro.algorithms.normalized-state#remove-entity

I haven't seen any errors in the .shadow-cljs/server.stderr.log come up while doing this.

@cjmurphy I changed integrate-mutation-return-value! to:

(>defn integrate-mutation-return-value!
  "If there is a successful result from the remote mutation in `env` this function will merge it with app state
  (if there was a mutation join query), and will also rewrite any tempid remaps that were returned
  in all of the possible locations they might be in both app database and runtime application state (e.g. network queues).

  Typically used as part of the construction of a global default result handler for mutations.

  Returns env."
  [env]
  [::env => ::env]
  (print "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx")
  env
  #_

I would then do the same with its caller, default-result-action! . That seems to then be everything that affects your app state.

I've narrowed it down to rewrite-tempids!.

Must be something in my code I guess. Hmm :thinking_face:

Yes. Always been a candidate. But I never mentioned it because it is supposed to only do anything when your return map has a tempids key, which yours does not. But there is some kind of cache there - I was just looking at the code.

And the cache is kept in app state. At least you are in the world of source code again, even if still some more trial and error...

I did have previously returned a tempids map in that mutation, but that code has been deleted for a while.

It was also pretty cool to see how you can hack around on library code using shadow-cljs. Haven't done that prior to now.

So a browser fresh (F5) would have solved the problem (by starting app state fresh)? And yes including the source code much easier these days. I've been using it more and more with RAD.

Nope, browser refresh doesn't solve it. Still having that same issue.