"Disk count not same as ram count."

[Joncom]

After cloning the latest from Github, and running the http example in the examples folder, I get this repeating message, after a few minutes of use.

Disk count not same as ram count.

% node http    
Hello wonderful person! :) Thanks for using GUN, please ask for help on http://chat.gun.eco if anything takes you longer than 5min to figure out!
AXE enabled.
Relay peer started on port 8765 with /gun
Multicast on 233.255.255.255:8765
Disk count not same as ram count.
Disk count not same as ram count.
Disk count not same as ram count.
Disk count not same as ram count.
Disk count not same as ram count.
Disk count not same as ram count.
Disk count not same as ram count.
Disk count not same as ram count.
Disk count not same as ram count.
Disk count not same as ram count.
Disk count not same as ram count.
Disk count not same as ram count.
Disk count not same as ram count.
Disk count not same as ram count.
Disk count not same as ram count.
Disk count not same as ram count.
Disk count not same as ram count.
Disk count not same as ram count.
Disk count not same as ram count.
Disk count not same as ram count.
Disk count not same as ram count.
Disk count not same as ram count.
Disk count not same as ram count.

"Well, what were you doing when it happened?"

I get() and put() plenty of data, but I don't feel like I'm doing anything particularly unconventional.

[shocknet-justin]

seeing this too, sporadically while troubleshooting

node peer => node client

[diatche]

I was getting the same message occasionally in Node.

Saw an explanation by Mark Nadal in Discord chat which may be of help to someone who knows more about Gun's inner workings than me:

[Disk count not same as ram count] means if 10 records were sent, RAD expected to save 10 records, but X records went missing - usually an invalid update that SEA rejects as not having the correct permission/authorization.

[Joncom]

[Disk count not same as ram count] means [that] records went missing - usually [due to] an invalid update that SEA rejects

Pretty sure I wasn't even using SEA while experiencing these errors.

[amark]

Thank you @diatche for documenting that.

@Joncom I had to rewrite RAD during 2019 to 2020 and yes, since I was making very experimental changes, I wanted to make sure I had a clear alarm bell go off during my tests if during the complex batching process there wasn't any accidents.

If you're not using SEA (it runs by default, note) and you see that, then probably should be concerned - can you give me an example of what type of data you're saving? If it isn't persisting, I'd like to set up a PANIC test to make sure whatever you're seeing doesn't continue happening.

[Joncom]

Hard to say. I was rapidly reading and writing a lot of different data to and from the database at the time.

[diatche]

I've started to see a pattern for this error with my implementation. My data is very basic with a couple of nodes deep into user land. No sets. Steps to reproduce (not 100% on this yet though, see below):

1. Set up a remote peer and connect a local node instance and a browser from two different machines to it. Don't add the local peer.
2. Create and sync user U in the browsers.
3. Take the remote peer offline. (Or take it offline for a short time)
4. Add data to user U in the first browser.
5. Bring remote peer online.
6. Reload the browser the second browser.
7. When it reloads and syncs, you should see Disk count not same as ram count.

I'm not 100% on this yet, but the state of the local node instance may be a factor. I've noticed that my node instance hangs every now and then. Considering that the only peer is a free Heroku instance, which is reset regularly, the node instance might be stopping sync after the remote Heroku instance goes offline briefly. Only after restating the local node instance and reloading the browser does everything go back to normal.

[shocknet-justin]

Seeing a lot of data come back as null that shouldn't be, this data is seen fine by several users but not all. In cases where this is occurring, the ram count error is more pervasive than usual. All of our data is User Graph to User Graph.