Gun: Using super-peer instead of local doesn't store sets?

Created on 16 Jan 2019 · 6Comments · Source: amark/gun

I'm running into a possible issue tyring to setup a super-peer.
If I use the small example below in browser w/o a super-peer:
var gun = Gun()
var bob = gun.get('bob').put({name: "Bob"});
var dave = gun.get('dave').put({name: "Dave"});
dave.get('friends').set(bob);
bob.get('friends').set(dave);

In browser shows:
{bob: {_: {#: "bob", >: {name: 1547665737707, friends: 1547665737715}}, name: "Bob",…},…}
bob: {_: {#: "bob", >: {name: 1547665737707, friends: 1547665737715}}, name: "Bob",…}
dave: {_: {#: "dave", >: {name: 1547665737711, friends: 1547665737712}}, name: "Dave",…}
jqzk7y0i6QEvvOZ0cnD4: {_: {#: "jqzk7y0i6QEvvOZ0cnD4", >: {bob: 1547665737712}}, bob: {#: "bob"}}
jqzk7y0kfMX0e0vw21um: {_: {#: "jqzk7y0kfMX0e0vw21um", >: {dave: 1547665737715}}, dave: {#: "dave"}}

The friends set seems to be created fine. Yet changing to:
var gun = Gun(location.origin + '/gun')

In browser shows:
{bob: {_: {#: "bob", >: {name: 1547665872453}}, name: "Bob"},…}
bob: {_: {#: "bob", >: {name: 1547665872453}}, name: "Bob"}
dave: {_: {#: "dave", >: {name: 1547665872457}}, name: "Dave"}

With no friends set being created. The "radata/" dir on server does not show any evidence of them being there either.

Source

Sarajin

Most helpful comment

This may be related to #687, because set is a wrapper around put.

Have you tried the following?

dave.get('friends').put({}).set(bob);

If that works, the issue is the same as the just-mentioned one, with the 'friends' path not existing while writing a child to it.

finwo on 17 Jan 2019

😄1 👍1

All 6 comments

This may be related to #687, because set is a wrapper around put.

Have you tried the following?

dave.get('friends').put({}).set(bob);

If that works, the issue is the same as the just-mentioned one, with the 'friends' path not existing while writing a child to it.

finwo on 17 Jan 2019

😄1 👍1

Ok, That apparently is the issue then. As it does seem to be working.

Thanks for pointing that out.

Sarajin on 17 Jan 2019

It's been described in the wiki: https://github.com/amark/gun/wiki/API#put under 'undefined behavior'.

The issue is gun not being able to find the path to place the object on because the server never responds data (makes sense, the data requested by the client does not exist).

finwo on 17 Jan 2019

@finwo @Sarajin oye, is this a regression or has this always not been working?

The way things should work is... remote peers reply "not found" and then current peer goes "okay, I'll generate new souls/IDs very every object beneath that point, since none exist to merge with already." and then it SHOULD create & put & save the data, not just... stall out.

In one of the other threads, I pointed to a couple LOC in GUN that I recently updated/changed (in last couple months) to deal with false-positives that were overly eager, but now it seems like maybe these are overly-strict and causing problem of way-too-conservative and stalling out.