Strange return Object from DHT Linked Call

oohh hooraaah!!!
just restarted everything and ran through local sim2h_server with success. A bit odd though as I didn’t change anything other than move to a local sim2h:

My Cell Data: Text(

@simwilso I suspect that what’s happening here is that the function takes so long that it often gives an opportunity for the conductor to emit a stats signal while the client is waiting for the get_signals function to return. That, combined with the fact that the new sim2h server has fixed a lot of the DHT bottlenecks that probably were partly to blame for get_signals taking so long, is probably why you’re seeing inconsistent results.

I think it’s important to point out that, even though you might get the right response 90% of the time, there’s still a chance that the stats signal (or the return value of another function that’s quicker) could weasel its way in there before your zome function call returns a value. The most robust way to prevent the edge cases would be to filter out those stats signals and wait for the actual JSON-RPC message that contains your return value. That’s what hc-web-client does (well, actually, it keeps the signals and allows you to subscribe to them with a listener).

This is totally feasible to roll-your-own, starting with the code you’ve got already. The important thing is to generate a unique ID for every JSON-RPC call so it can be matched up with the response. If your client ever wanted to listen to signals in the future (e.g., zome-emitted signals, you could just trigger handler functions whenever those signals come in.

In a way this might be better than using an off-the-shelf JSON-RPC lib, because it will throw out everything that doesn’t look like a JSON-RPC response. So if you want to listen for signals as well as make zome calls, you need to open up an extra socket just for signals. This problem doesn’t exist if you roll your own lib.