ouff... are the upper backtraces from the server window or the client?
I somehow assum(ed) that patchbay reconnects if the bot goes away(?) So I guess the sbot really does crash? maybe try running it with an external sbot to make sure to get the output?
(i could go on a rant about how pull-stream backtraces drove me to re-implement this stuff butt that doesn't help so I will leave it at that.)
Here's a couple of weird things I've seen while working on private-groups
branch of patchbay:
- long running patchbay seems to crash
interface loses connection to active sbot I think, and we see these errors:
Error: unexpected hangup
at Object.cb (/projects/patchbay/node_modules/pull-box-stream/index.js:117)
at drain (/projects/patchbay/node_modules/pull-reader/index.js:46)
at /projects/patchbay/node_modules/pull-reader/index.js:63
at /projects/patchbay/node_modules/pull-reader/index.js:114
at drain (/projects/patchbay/node_modules/stream-to-pull-stream/index.js:126)
at Socket.<anonymous> (/projects/patchbay/node_modules/stream-to-pull-stream/index.js:143)
at Socket.emit (events.js:187)
at endReadableNT (_stream_readable.js:1092)
at process._tickCallback (internal/process/next_tick.js:63)
Exception thrown by PacketStream substream end handler Error: unexpected end of parent stream
at PacketStream.destroy (/projects/patchbay/node_modules/packet-stream/index.js:71)
at PacketStream.write (/projects/patchbay/node_modules/packet-stream/index.js:133)
at /projects/patchbay/node_modules/muxrpc/pull-weird.js:58
at /projects/patchbay/node_modules/pull-stream/sinks/drain.js:20
at /projects/patchbay/node_modules/pull-goodbye/node_modules/pull-stream/throughs/filter.js:17
at Object.cb (/projects/patchbay/node_modules/packet-stream-codec/index.js:98)
at drain (/projects/patchbay/node_modules/pull-reader/index.js:46)
at /projects/patchbay/node_modules/pull-reader/index.js:63
at drain (/projects/patchbay/node_modules/stream-to-pull-stream/index.js:126)
at Socket.<anonymous> (/projects/patchbay/node_modules/stream-to-pull-stream/index.js:143)
at Socket.emit (events.js:187)
at endReadableNT (_stream_readable.js:1092)
at process._tickCallback (internal/process/next_tick.js:63)
- weird "key not found" error
Doesn't seem to break anything.
Strangely if I look for that key it is in my db...
{ message:
'Key not found in database [%HxkteNyUYaPdfvGrj8FfQKMbG6f022fFB7xy49c9pKA=.sha256]',
name: 'NotFoundError',
stack:
'NotFoundError: Key not found in database [%HxkteNyUYaPdfvGrj8FfQKMbG6f022fFB7xy49c9pKA=.sha256]\n at /projects/patchbay/node_modules/levelup/lib/levelup.js:188:15\n at /projects/patchbay/node_modules/encoding-down/index.js:75:21' }
- this error in the log
may be related to (2) ... or not?could not retrive msg: Error { notFound: true, status: 404 }
Oh! Looping back- this all seemed fine and to work as expected. I was presuming things would be more immediate given I am following the pub directly but it seemed like there was actually a few minutes delay in propagation.
Final issue is syncing profile data- doesn't seem to be working but I've probably done something silly.
- Used the pub's invite code myself and I now appear to be following.
- Ran this command, which seemed to succeed fine based on the output:
ssb-cli publish --type about --about "@XRK+1O0EDeGEHP3hlfhLIR5C5FGFnxmMwBThI41TRZc=.ed25519" --name ssb.spadgos.com
- No change to what I can see in patchwork, doesn't seem to be updating its profile?
Oh, looping back...
For anyone else who hits these problems and is using CloudFlare, DNS is probably your issue.
I had to add a specific A
record in their control panel for the subdomain my pub is being served from, pointing directly to my origin server with "proxy status" set to "DNS only". This prevents the subdomain from redirecting to CloudFlare's servers and not actually hitting your pub directly.
Also switched over to ssb-daemon
/ ssb-cli
(was only a couple of lines of config changes), seems to be working well!
Show whole feed