git ssb

I'm consistently getting long streams of errors that seem mostly related to connections. It's hard to tell which, if any, of these are actually affecting syncing, or are just normal early terminations.

Because there's so many of them, it's also had to see other debug messages. So I guess there's two thoughts:

1. handling these errors in a way that makes it easier to track them, and
2. addressing what is causing them in the first place.

Perhaps these have been discussed or are known already; if so, apologies for the duplicates! Happy to help if I can :).

Errors

(I have screenshots of these but can't attach images here so am not copying the full stacktrace, but can post those somewhere if they are useful).

Error: write EPIPE at exports._errnoException (util.js:1022:11) at WriteWrap.afterWrite [as oncomplete] (net.js:804:14)

Error: unexpected end of parent stream

server error Error: wrong number

Error: unexpected hangup

I brought this up with @cel and @noffle at NodeSchool Oakland today. Turns out everybody gets lots of erorr output from sbot. It's working!

Agree it's confusing to see a lot of errors when something is working properly. An issue, but not an urgent one, I take it. Folks using sbot today probably aren't so spooked by stack traces as most.

it's not so great when long stream lead to sbot hanging. this is quite common for me

One thing I only just noticed in the unexpected end of parent streams

Feb 12 17:15:58 tingSub scuttlebot[26973]: Error: unexpected end of parent stream
Feb 12 17:15:58 tingSub scuttlebot[26973]: at PacketStream.destroy (/home/keks/src/scuttlebot/node_modules/scuttlebot/node_modules/muxrpc/node_modules/packet-stream/index.js:68:7)
Feb 12 17:15:58 tingSub scuttlebot[26973]: at Object.ws.close (/home/keks/src/scuttlebot/node_modules/scuttlebot/node_modules/muxrpc/stream.js:134:23)
Feb 12 17:15:58 tingSub scuttlebot[26973]: at EventEmitter.emitter.close (/home/keks/src/scuttlebot/node_modules/scuttlebot/node_modules/muxrpc/index.js:69:8)
Feb 12 17:15:58 tingSub scuttlebot[26973]: at /home/keks/src/scuttlebot/node_modules/scuttlebot/plugins/gossip/index.js:164:20
Feb 12 17:15:58 tingSub scuttlebot[26973]: at Array.forEach (native)
Feb 12 17:15:58 tingSub scuttlebot[26973]: at EventEmitter.gossip.reconnect (/home/keks/src/scuttlebot/node_modules/scuttlebot/plugins/gossip/index.js:163:30)
Feb 12 17:15:58 tingSub scuttlebot[26973]: at emitNone (events.js:67:13)
Feb 12 17:15:58 tingSub scuttlebot[26973]: at EventEmitter.emit (events.js:166:7)
Feb 12 17:15:58 tingSub scuttlebot[26973]: at null._repeat (/home/keks/src/scuttlebot/node_modules/scuttlebot/node_modules/on-wakeup/index.js:16:17)
Feb 12 17:15:58 tingSub scuttlebot[26973]: at wrapper [as _onTimeout] (timers.js:275:11)

is that you see the file location from the other end in the errors..!?

here is the full err.log dump for better readability.

dominic ones explained the amount of these erorrs with muxrpc. Since all the sbot calls get multiplex inside it, when the master connection dies all of the streams get torn apart and individually fail.

@kemitchell sweet thanks. agree it doesn't seem to be actually crashing anything... most of the time ;). main issue is that there's no way to differentiate between more and less significant errors with that much noise, which i suppose is mnimally a bit annoying for those who actually like to understand stack traces, and perhaps in the worst case will hinder our collective ability to support with debugging or fixes.

at the same time, presumably most of us could help fix it and aren't, so i guess that's also an implicit statement of significance. :)