If you return an empty map {} from your server mutation does that fix the problem?

http://book.fulcrologic.com/#ReturnValues

@U0D5RN0S1 nope, returning an empty map doesn't fix it. Same result.

So this would happen if your server mutation that did nothing and returned {} ? I want to rule out something else from the server affecting the client.

That's correct. I commented out the swap! form and just have it returning {} and it still happens.

And do the same for all your server mutations perhaps? Also what about loads from the client? Gonna have to rule everything else out.

It's my only server mutation at this point, so that should make things simpler 🙂

What/how should I check about client loads?

df/load search for that. That really does affect your client state, that's what it is supposed to do.

And then there is merge - two ways to do that.

From my ui the mutation is just called as such:

(div :.wide.column
          (dom/i :.ui.right.floated.icon.trash.alternate.outline
            {:onClick #(comp/transact! this [(m/delete-note {:note/id id})])}))

That's all there is to it, nothing else.

Is that :node/id being picked up on the server? I don't trust a mutation like that without and ~. Not that that's solving your problem. And I do know there is a way to get away with using and ~, just never used it.

I guess it is working b/c it calls the client part of the mutation, the action part.

@U0D5RN0S1 yeah, the parameter is coming through to the mutation. I can log it.

The note-table atom even gets updated to remove the requested note, when I have the code uncommented.

Have you tested with different versions of Fulcro? Submit a bug (especially) if everything works as expected with older versions. There is this open issue: https://github.com/fulcrologic/fulcro/issues/433. Different to yours but in the same area.

@U0D5RN0S1 Oh, interesting. Thanks for the link. I'm going to test that tomorrow and report if it works in another version.

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

@U797MAJ8M > 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.

@U0D5RN0S1 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.