If Gun will lose connection with super-peer, IT WILL NEVER RECONNECT!

[brailateo]

Found bug in gun.js that can be found today at https://cdn.jsdelivr.net/npm/gun/gun.js
In function reconnect(peer) , after line 1777 ( clearTimeout(peer.defer); ) I added a single line
console.log("I'm in reconnect, opt=",opt);
After 1 reconnect attempt you fill find the opt variable empty {} so the reconnect function will NEVER be called again because of the next line:
if(!opt.peers[peer.url]){ return }

So I just comment out that line and everything is OK!

Test procedure AFTER operating my hack:

1. check if super-peer is up and running
2. run a simple Gun app in 2 browsers, A and B , check app if working and get updates each other
3. stop the super-peer server
4. your app in A and B servers are running, updating their own local storage, reconnect is called at 2 seconds for many times
5. after 30 seconds or more, start super-peer again
6. your app in A and B browser are reconnecting just fine, everything is ok

Your app document updates during network failure simulation ARE saved in local storage of browsers, they are NOT automatically pushed to other peers or super-peer upon reconnection but I'm feeling that it's not possible, yet! Anyway, I found a "TODO: resync upon reconnect online/offline" at line 1734 and I suppose that it might be possible sometime?
Anyway, updates during offline time are delivered to other peers from local storage WHEN REQUESTED by other peers, so it's not a show-stopper, probably apps should be designed with periodically auto-refresh.

Best regards,
Teo

[amark]

it should be defaulting to 60 retries, no? But you're saying an opt|| bug causes it to only retry 1? That sounds bad. Please send PR! (tho please don't let it infinitely retry)

[brailateo]

I'm sorry @amark but I cannot send a PR because:

1. I didn't understood quite well the source around open() function
2. I feel that the fix should be like: abandon the re-connection after N minutes (configurable in options) for normal (WebRTC) peers and NEVER for super-peers relays and I don't know how to detect what kind of peer is it
3. I think that this bug should be tested previously by someone with better understanding of the source code ( a simple console.log added there after line 1777 and then kill the super-peer would be enough to check it)
4. I'm some kind of old dog programmer not very familiar with new tricks so ... I don't know how to PR :-(

Best regards,
Teo