- Readloop goroutine gets a new request (incoming message), sends to
incoming loop
- Incoming request loop goroutine calls incoming message handler
- Incoming message handler needs group info, sends a WS request
- Sendloop goroutine gets request, sends on WS, stores response channel
in map
- Incoming message handler is blocked waiting on response on it's
response channel
- Readloop gets some other request, tries to send to incoming loop, but
gets blocked on sending to incoming request channel because it's
unbuffered and that goroutine is still blocked waiting on group info
- Server responds with response to group info request, but readloop is
blocked now forever
The fix: give the incomingRequestChan a large (10000) buffer. Now:
- Readloop goroutine gets a new request (incoming message), sends to
incoming loop
- Incoming request loop goroutine calls incoming message handler
- Incoming message handler needs group info, sends a WS request
- Sendloop goroutine gets request, sends on WS, stores response channel
in map
- Incoming message handler is blocked waiting on response on it's
response channel
- Readloop gets some other request and successfully buffers it in the
incoming request channel
- Server responds with response to group info request, readloop is *not*
blocked, and can pass the response down the response channel that the
incoming message handler is blocked on, and it can finish up
- Incoming request loop is free to continue processing incoming requests
Well enough anyway. When the old prekeyDecrypt fails due to null
pointer, fall through to sealedSenderDecrypt, which usually seems to be
able to decrypt it fine
Had to use storage.signal.org, and had to ignore a very misleading
AuthCredentialPresentation lengths in the FFI header, it was leading me
to improperly truncate the presentation before sending >:(
