The original fix only wrapped the RPC handshake decode. The user's
symptom is the same error after the RPC handshake succeeds (the kRPC
server registers the client on the RPC side), so the failure must
be in the stream handshake.
Added:
- try/catch around the stream decode (matching the RPC decode)
- KRPC_DEBUG env var that dumps raw bytes from both handshakes
to the console. Set it to 1 when running the bridge to see
exactly what kRPC is sending:
KRPC_DEBUG=1 pnpm start
Output will include lines like:
[krpc-client] rpc handshake raw response (17 bytes): 08001200...
[krpc-client] stream handshake raw response (4 bytes): 08001200
Mavis
25dd42503b