[Bug] Tunnel node ignores batch size limit on raw MP4 streams, causing 50MB Apps Script truncation

[bankbunk]

Describe the bug
When streaming raw .mp4 video files in Full Tunnel mode, mhrv-tunnel-node appears to ignore batch size limits. Because my VPS has a high-speed connection (1 Gbps), it aggressively buffers the video data and packs it into a single massive JSON payload.

The batch hits exactly ~52.4MB, which triggers Google Apps Script's hard memory limit. Google truncates the response, causing the Rust client to crash and instantly kill the video stream.

Log
ERROR batch JSON parse error: EOF while parsing a string at line 1 column 52428685

Workaround / Proof of Cause
I confirmed this is caused by the buffer filling too fast. When I used wondershaper to strictly limit the VPS network interface to 40 Mbps, the stream worked perfectly because the node was forced to send manageable chunks.

[therealaleph]

@bankbunk — exceptional bug report. The proof-of-cause via wondershaper was the kind of evidence that lets us go straight to the fix without back-and-forth diagnostics. Thank you.

Root cause matches your analysis exactly:

drain_now in tunnel-node/src/main.rs was taking the entire per-session read buffer in one shot — no upper bound. On your 1 Gbps VPS, the reader task can stuff the buffer with tens of MiB between client polls. The resulting batch response, after base64 encoding (~1.33× multiplier) and JSON envelope, exceeded Apps Script's ~50 MiB hard ceiling on Web App response bodies. Apps Script truncated the body mid-base64 → the client's serde_json parse failed at the truncation column (yours: column 52428685 = exactly 50 MiB) → stream tore.

Fix shipped in v1.8.5 (just tagged, release CI building now):

const TCP_DRAIN_MAX_BYTES: usize = 16 * 1024 * 1024;  // 16 MiB

async fn drain_now(session: &SessionInner) -> (Vec<u8>, bool) {
    let mut buf = session.read_buf.lock().await;
    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 {
        let tail = buf.split_off(TCP_DRAIN_MAX_BYTES);
        let head = std::mem::replace(&mut *buf, tail);
        // Hold EOF back until buffer is fully drained — partial drains
        // shouldn't prematurely close the session.
        (head, false)
    }
}

Why 16 MiB and not 32 or 40:

• Apps Script body cap is ~50 MiB (52,428,800 bytes — your truncation column matches).
• Base64 inflates raw bytes by 1.33× → 16 MiB raw → ~21.3 MiB encoded.
• JSON envelope ({"r": [{"sid": "...", "d": "...", "eof": false}]}) adds a few hundred bytes.
• serde_json::to_vec on a single ~21 MiB string is also a per-batch CPU spike on tunnel-node — leaning back further at 16 MiB lets the encoder breathe.
• Headroom for any future framing changes (xmux v1.9.0 will add reordering metadata per chunk).

The headroom is generous on purpose. We can revisit later if throughput measurements show the cap is leaving bandwidth on the table.

On EOF correctness:

Subtle issue: if upstream signals EOF while the buffer still has more than 16 MiB, the first drain returns eof: false even though session.eof is set. Otherwise the client would close the session after the first drain and miss the tail. EOF flips on the final drain that returns a sub-cap buffer. Three regression tests cover this (cap pass-through, under-cap pass-through, EOF holdback) — all 33 tunnel-node tests passing.

Your wondershaper workaround is no longer necessary. Remove the rate-limit, restart mhrv-tunnel after pulling the new image (docker pull ghcr.io/therealaleph/mhrv-tunnel-node:latest && docker stop mhrv-tunnel && docker rm mhrv-tunnel && docker run -d ...), and you should see line-rate throughput on MP4 streams without truncation.

Throughput expectation after fix:

With 16 MiB chunks and Apps Script's 30s response cliff:

• Each batch round-trip: ~250-500ms typical for the Apps Script leg
• 16 MiB per round-trip × 4 round-trips/sec ≈ ~64 MiB/sec ≈ ~512 Mbps theoretical ceiling per single deployment
• Practical: ~50-200 Mbps depending on Apps Script latency variance + Iran ISP throttle

For 1 Gbps VPS users: bandwidth is no longer the bottleneck for single-stream downloads. Multi-deployment routing already aggregates across deployments. v1.9.0's xmux will further parallelize at byte-range level for even higher single-stream throughput.

Confirmation request: after upgrading to v1.8.5 (download in ~30 min from https://t.me/mhrv_rs or the release page) and removing the wondershaper rate-limit, please confirm the fix on your end with a few minutes of MP4 streaming. If it holds, this issue closes as resolved. If anything still tears, paste the new log line + any trace and we'll dig further.

This issue stays open until your confirmation.

---

_{[reply via Anthropic Claude | reviewed by @therealaleph]}

[bankbunk]

Thanks fixed!