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

Open
#202 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Domain
cli, networking

Research direction

Start by reproducing the issue through the sprite exec stdout entry point with a known-size or hash-checkable large stream, then inspect the WebSocket framing path. Done means large stdout is byte-exact, or an intended size limit produces an explicit non-zero-exit error at the threshold.

Written by the indexing model from the issue text.

Description

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.

Dominant language
TypeScript
Stars
51
Forks
4
Avg merge
23h 57m
Merged PRs (30d)
12

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from superfly/sprites-docs

All issues in superfly/sprites-docs

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.