fix: v1.8.5 — tunnel-node caps TCP drain at 16 MiB to stay under Apps Script body ceiling

@bankbunk reported (#460) that on a 1 Gbps VPS, raw MP4 streams in Full
mode died with `batch JSON parse error: EOF while parsing a string at
line 1 column 52428685` minutes into playback. Root cause: drain_now
took the entire per-session read buffer in one shot. On high-bandwidth
VPS the reader task fills the buffer with tens of MiB between polls;
the resulting batch response (raw + base64 1.33× + JSON envelope)
exceeded Apps Script's ~50 MiB hard cap; Apps Script truncated mid-base64;
the client's serde_json parse hit EOF and the stream tore.

Fix: drain_now now returns at most TCP_DRAIN_MAX_BYTES (16 MiB) per call
and leaves the tail in the buffer for the next poll. EOF is held back
until the buffer is fully drained so partial drains don't tear the
session prematurely. Three regression tests cover the cap, the under-cap
pass-through, and the EOF-holdback case (33 tunnel-node tests passing).

@bankbunk's wondershaper rate-limit workaround (40 Mbps cap on the VPS
interface) is no longer necessary — high-bandwidth VPS users can run at
line rate again.

Author: therealaleph

Cargo.lock

@@ -1,6 +1,6 @@
 [package]
 name = "mhrv-rs"
-version = "1.8.4"
+version = "1.8.5"
 edition = "2021"
 description = "Rust port of MasterHttpRelayVPN -- DPI bypass via Google Apps Script relay with domain fronting"
 license = "MIT"

Cargo.toml

@@ -0,0 +1,4 @@
+<!-- see docs/changelog/v1.1.0.md for the file format: Persian, then `---`, then English. -->
+• fix tunnel-node: cap هر TCP drain روی ۱۶ MiB تا batch response از سقف Apps Script (~۵۰ MiB) عبور نکنه ([#460](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/issues/460) از @bankbunk): روی VPS های پر-bandwidth (۱ Gbps) reader task می‌تونه هزاران مگابایت رو در buffer per-session جمع کنه قبل از اینکه poll بعدی بیاد. قبلاً `drain_now` همه‌ی buffer رو در یک batch response می‌گرفت، base64 encoding (~۱.۳۳×) + JSON envelope اضافه می‌کرد، نتیجه از سقف ۵۰ MiB Apps Script رد می‌شد. Apps Script body رو wrap-around mid-base64 کوتاه می‌کرد + client side `serde_json` parse error با `EOF while parsing a string at line 1 column 52428685` می‌گرفت. برای استریم MP4 یا هر بایت‌سنگین upstream این bug stream رو مرتب کرش می‌داد. حالا `drain_now` حداکثر ۱۶ MiB در هر poll برمی‌گردونه + tail رو در buffer برای poll بعدی نگه می‌داره. eof تا finalize شدن buffer reported نمی‌شه که session بی‌موقع tear نشه. workaround قبلی @bankbunk (محدودکردن interface VPS با `wondershaper` به ۴۰ Mbps) دیگر لازم نیست — fix server-side پیاده شد و کاربران throughput عادی VPS رو خواهند داشت
+---
+• Fix tunnel-node: cap each TCP drain at 16 MiB so batch responses stay under Apps Script's ~50 MiB body ceiling ([#460](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/issues/460) by @bankbunk): on high-bandwidth VPS (1 Gbps+), the reader task can stuff the per-session read buffer with tens of MiB between client polls. The old `drain_now` took the entire buffer in one shot, base64-encoded it (1.33× overhead), wrapped it in JSON, and the resulting body exceeded Apps Script's hard ~50 MiB Web App response limit. Apps Script truncated the body mid-base64; the client failed `serde_json` parse with `EOF while parsing a string at line 1 column 52428685` (= 50 MiB) and the stream tore. Most visibly, raw MP4 streams crashed minutes into playback. The fix splits oversized buffers: at most `TCP_DRAIN_MAX_BYTES` (16 MiB) is returned per drain, and the remainder stays in the buffer for the next poll. EOF is held back until the buffer is fully drained so partial drains don't prematurely close the session. Three regression tests cover the cap, the under-cap pass-through, and the EOF-holdback case (33 tunnel-node tests passing). @bankbunk's `wondershaper` workaround (rate-limiting the VPS interface to 40 Mbps) is no longer necessary — high-bandwidth VPS users can let throughput run at line rate again.

docs/changelog/v1.8.5.md

@@ -83,6 +83,22 @@ const UDP_QUEUE_LIMIT: usize = 256;
 /// a maximum-size IPv4 datagram without truncation.
 const UDP_RECV_BUF_BYTES: usize = 65536;
 
+/// Maximum raw bytes per TCP drain that we hand back to Apps Script in
+/// one batch response. Apps Script's hard cap on Web App response body
+/// is ~50 MiB. Accounting for base64 encoding (1.33×) and JSON envelope
+/// overhead, the safe ceiling for raw bytes is roughly 32 MiB — but
+/// `serde_json::to_vec` for a single 32-MiB string is also a CPU spike,
+/// so we lean further back at 16 MiB. On a high-bandwidth VPS (1 Gbps+)
+/// the reader task can stuff the per-session buffer with tens of MiB
+/// between polls (issue #460); without this cap, `drain_now` would take
+/// the lot, the response would exceed Apps Script's ceiling, the body
+/// would be truncated mid-base64, and the client would fail JSON parse
+/// with `EOF while parsing a string at line 1 column ~52428685`. By
+/// returning at most this many bytes per drain and leaving the rest in
+/// the read buffer for the next poll, we keep responses comfortably
+/// under the cap and let throughput recover across batches.
+const TCP_DRAIN_MAX_BYTES: usize = 16 * 1024 * 1024;
+
 /// First queue-drop on a session always logs at warn level; subsequent
 /// drops log at debug only every Nth occurrence so a single congested
 /// session can't flood the operator's log.
@@ -324,13 +340,33 @@ async fn udp_reader_task(socket: Arc<UdpSocket>, session: Arc<UdpSessionInner>)
     }
 }
 
-/// Drain whatever is currently buffered — no waiting.
-/// Used by batch mode where we poll frequently.
+/// Drain up to `TCP_DRAIN_MAX_BYTES` from the per-session read buffer —
+/// no waiting. Used by batch mode where we poll frequently.
+///
+/// If the buffer is larger than the cap, we return a prefix of the
+/// data and leave the remainder in the buffer for the next poll. The
+/// cap exists to keep batch responses under Apps Script's ~50 MiB body
+/// ceiling on high-bandwidth VPS — see `TCP_DRAIN_MAX_BYTES` for the
+/// underlying issue (#460).
+///
+/// `eof` is reported as true only when the buffer has been fully
+/// drained AND upstream has signaled EOF — otherwise a partial drain
+/// would prematurely tear the session down on the client side.
 async fn drain_now(session: &SessionInner) -> (Vec<u8>, bool) {
     let mut buf = session.read_buf.lock().await;
-    let data = std::mem::take(&mut *buf);
-    let eof = session.eof.load(Ordering::Acquire);
-    (data, eof)
+    let raw_eof = session.eof.load(Ordering::Acquire);
+    if buf.len() <= TCP_DRAIN_MAX_BYTES {
+        let data = std::mem::take(&mut *buf);
+        (data, raw_eof)
+    } else {
+        // Take the prefix; leave the tail in the buffer.
+        let tail = buf.split_off(TCP_DRAIN_MAX_BYTES);
+        let head = std::mem::replace(&mut *buf, tail);
+        // Don't propagate eof yet — buffer still has data even if upstream
+        // has closed. The client will get eof on the drain that returns
+        // an empty (or sub-cap) buffer.
+        (head, false)
+    }
 }
 
 /// Block until *any* of `inners` has buffered data, hits EOF, or the
@@ -1590,6 +1626,61 @@ mod tests {
         })
     }
 
+    #[tokio::test]
+    async fn drain_now_caps_at_tcp_drain_max_bytes() {
+        // Issue #460: a 1 Gbps VPS reader fills the buffer with tens of MiB
+        // between polls; drain_now used to take the lot, the JSON response
+        // exceeded Apps Script's body cap, and the client failed JSON parse.
+        // The cap leaves the tail in the buffer for the next drain.
+        let inner = fake_inner().await;
+        let oversized = TCP_DRAIN_MAX_BYTES + 4096;
+        inner.read_buf.lock().await.resize(oversized, 0xab);
+
+        let (first, eof) = drain_now(&inner).await;
+        assert_eq!(first.len(), TCP_DRAIN_MAX_BYTES);
+        assert!(!eof, "shouldn't propagate eof while buffer still has data");
+
+        // Tail remains for the next poll.
+        assert_eq!(inner.read_buf.lock().await.len(), 4096);
+
+        let (second, _) = drain_now(&inner).await;
+        assert_eq!(second.len(), 4096);
+        assert!(inner.read_buf.lock().await.is_empty());
+    }
+
+    #[tokio::test]
+    async fn drain_now_passes_through_when_under_cap() {
+        let inner = fake_inner().await;
+        inner.read_buf.lock().await.extend_from_slice(b"hello world");
+
+        let (data, eof) = drain_now(&inner).await;
+        assert_eq!(data, b"hello world");
+        assert!(!eof);
+        assert!(inner.read_buf.lock().await.is_empty());
+    }
+
+    #[tokio::test]
+    async fn drain_now_holds_eof_until_buffer_drained() {
+        // If upstream signals EOF while the buffer is still oversized, we
+        // must drain the head, leave the tail, and *not* set eof yet.
+        // Eof flips on the final drain that returns a sub-cap buffer.
+        let inner = fake_inner().await;
+        inner.eof.store(true, Ordering::Release);
+        inner
+            .read_buf
+            .lock()
+            .await
+            .resize(TCP_DRAIN_MAX_BYTES + 100, 0);
+
+        let (head, head_eof) = drain_now(&inner).await;
+        assert_eq!(head.len(), TCP_DRAIN_MAX_BYTES);
+        assert!(!head_eof, "premature eof would tear the session");
+
+        let (tail, tail_eof) = drain_now(&inner).await;
+        assert_eq!(tail.len(), 100);
+        assert!(tail_eof, "eof finally flips when buffer is drained");
+    }
+
     #[tokio::test]
     async fn wait_for_any_drainable_returns_immediately_when_buffer_has_data() {
         let inner = fake_inner().await;