Bug: `sprite exec` stdout silently drops bytes by volume on large streams

[anuragit15]

Summary

sprite exec stdout silently drops bytes by volume on large outputs. There is no error and no non-zero exit — the receiving side just gets corrupted/truncated data.

Reproduction

Run an in-box command that emits a large, verifiable stream to stdout (e.g. a known-size payload or a hash-checkable blob) and compare what the host receives against what the box produced.

Observed in our usage:

• Corruption begins at roughly 512 KB of stdout.
• Loss reaches ~76% at around 4 MB.

The failure is silent: exit code 0, no stderr, no truncation marker — the bytes are simply missing.

Impact

Any workflow that moves a sizable payload through sprite exec stdout (for example a base64-encoded file, a large log, or a build artifact manifest) receives corrupted data with no signal that anything went wrong. This is especially dangerous because a naive integrity assumption ("exec succeeded, so stdout is complete") silently holds false.

Our workaround

We abandoned moving any sizable data through sprite exec stdout and route every transfer through sprite file pull/push instead, which is byte-exact in our testing (verified byte-for-byte to ~16 MB pull / ~8 MB push). We additionally carry a sha256 + byte-count header end-to-end and re-verify on landing, so a lossy channel surfaces as an integrity error rather than corrupt input.

Ask

Either:

• fix the WebSocket framing so sprite exec stdout is byte-exact for large streams, or
• if a hard size limit on exec stdout is intended, surface it as an explicit, non-zero-exit error at the threshold instead of silently truncating.

Happy to provide a minimal repro script if useful.