Gun: Reading data back from stats ruins the 'peers' configuration

[SunriseFox]

Reproduce by these steps:

1. Write these codes.

const gun = Gun({ web: server, multicast: false })
gun.opt({peers: ['somepeer1', 'somepeer2']}) // replace it

1. Start it and wait for 60 seconds.

2. Restart it.

3. The stats no longer works as expected. peers is turned to somepeer2. peers.count is equal to somepeer2.length

Bad codes:

// axe.js:151 
setInterval(function(tmp){
  if(!(tmp = at.stats && at.stats.stay)){ return }
  (tmp.axe = tmp.axe || {}).up = Object.keys(axe.up||{});
},1000 * 60)

```javascript
// lib/stats.js:29 write bad things to log
root.stats.stay = root.stats.stay || {};

```javascript
// lib/stats.js:24 read bad things from log
root.stats = Gun.obj.ify((fs.existsSync(__dirname+'/../stats.'+root.opt.file) && fs.readFileSync(__dirname+'/../stats.'+root.opt.file).toString())) || {};

// axe.js:155 ruin the configuration
setTimeout(function(tmp){
  if(!(tmp = at.stats && at.stats.stay)){ return }
  Gun.obj.map((tmp.axe||{}).up, function(url){ mesh.hear.opt({opt: {peers: url}}) })
},1000);

[amark]

@SunriseFox WELCOME TO THE COMMUNITY!!!! :D :D :) :) :) Thanks for the issue. What are you using GUN for?

Nice catch! I just shipped this recently, so probably buggy!

I tried replicating, but couldn't easily get it working and I'm stressed / headed off to dWeb camp for a week, offline.

I want to make sure that I'm not misunderstanding you, does this ruin stats themselves?

Or does it change which peers you are connected to?

A new default I've added is that in NodeJS, if a peer you are trying to connect to, fails to successfully connect after X of tries, GUN will stop trying to connect to that peer.

This is reflected in AXE as the axe.up stat.

To make sure this persists across restarts, I (bad!!!! I needed to publish this before I go to camp tomorrow) got lazy and saved/mutated the stats data. Such that, yes, on-start reading from stats might affect peer configuration.

Is what I have just explained the thing you are reporting? If so, we probably need to discuss more whether this "feature" should be revised, removed, or improved in the future.

Or, are you trying to explain that something else is going wrong (stats have wrong data in wrong places?), in the process of AXE reconfiguring peers based on uptime?

@SunriseFox also, holy wow! How'd you find/figure this out so fast? Did it break some of your existing code? Or have you just been tracking AXE development and thought this was curious/odd? Or ???

[SunriseFox]

Ah, that's simple. I found it because I set up GUN to connect to A and B then removed them from the peers list, but GUN keeps connecting to A and B, even though nothing in the code is related to A or B.

Another wired thing is that in stats.radata file, peers.count is always 30. so I logged peers out and found that peers is just the B 's server string (http://127.0.0.1:3000/gun).

Then I looked into GUN's source and searching for 1+ hours, and found the cause.

Conclusion:

before read the stats.radata, which contains

  "stay": {
    "axe": {
      "up": [
        "http://127.0.0.1:3000/gun"
      ]
    }
  },

, root.opt.peers are:

(object) {
  '1': 'http://127.0.0.1:3000/gun',
  'http://127.0.0.1:3000/gun': {
    url: 'http://127.0.0.1:3000/gun',
    id: 'http://127.0.0.1:3000/gun'
  }
}

after read the stats, root.opt.peers becomes:

(string) http://127.0.0.1:3000/gun

so the stats (peers.count always equals to the string's length) and the connection (always connect to the previous server even though the configuration no longer exists) are not working as expected.

[amark]

@SunriseFox oh I think I understand you now.

Shoot, I think this might break things for me... gonna try urgent patch now, and (ugh, will have to upgrade 9 raspis, but better than it not working! so THANK YOU, hopefully you helped catch something important before I ran off!).

[amark]

@SunriseFox should be quick fixed & published 712 :) thanks for reporting this, you might have just saved my butt at the conference!

[amark]

Also, if something is still broken on this, please let me know ASAP!

Plus I'd love to hear your story and what you are building! How'd you find GUN?

[Tedko]

@amark SunRiseFox just join us recently! :D:D

[amark]

@Tedko :D :D :D yay! Been meeting with Yisi a bunch too!

[Tedko]

👍👍👍😄😄

On Thu, Jul 25, 2019 at 01:51 Mark Nadal [e-mail] wrote:

@Tedko https://github.com/Tedko :D :D :D yay! Been meeting with Yisi a
bunch too!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/amark/gun/issues/771?email_source=notifications&email_token=ABTAVTMA5ZJA2UBUN45HHVTQBCJDRA5CNFSM4IEO33XKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2XDMZI#issuecomment-514733669,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABTAVTOFXEH342ZRAKTJQGDQBCJDRANCNFSM4IEO33XA
.