From 06ff8779bd10b1b10f3edc7ab13e6c4252e28917 Mon Sep 17 00:00:00 2001 From: Connor Peet Date: Mon, 1 May 2023 17:34:11 -0700 Subject: [PATCH] cli: tunnels can sporadically become unresponsive (#181285) Last iteration I moved some RPC logic to use Tokios "codecs" to give them cancellation safety. These operate on streams of input data. While this worked at first, I failed to take into account that the byte buffer we read from the stream could have _more_ data than just the current message under load scenarios. We were discarding any extra data from the subsequent message. In most cases caused the next message "length" to be read from the middle of the next message, which usually (when parsed as a u32) was some number of gigabytes, then causing the connection to stall forever. Fixes #181284 --- cli/src/msgpack_rpc.rs | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/cli/src/msgpack_rpc.rs b/cli/src/msgpack_rpc.rs index 18d5d0b9d2b..0350c1bfd64 100644 --- a/cli/src/msgpack_rpc.rs +++ b/cli/src/msgpack_rpc.rs @@ -3,6 +3,7 @@ * Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ +use bytes::Buf; use tokio::{ io::{AsyncRead, AsyncReadExt, AsyncWrite, AsyncWriteExt, BufReader}, pin, @@ -124,8 +125,8 @@ impl tokio_util::codec::Decoder for U32PrefixedCodec { return Ok(None); } - let msg = src[U32_SIZE..].to_vec(); - src.resize(0, 0); + let msg = src[U32_SIZE..required_len].to_vec(); + src.advance(required_len); Ok(Some(msg)) } }