Render hangs silently when disk is full instead of erroring

Open
  • Is something wrong?
#6 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Quiet
Tech stack
docker, typescript
Domain
cli

Research direction

The payload names no source files, only the frame-write path that calls fs.writeFile or fs.createWriteStream for each PNG/WebP and the bundle-write path under /tmp/rendiv-bundle-* and /tmp/rendiv-frames-*. Start by finding those writes and reproducing with a small tmpfs that fills up mid-render. Done means an ENOSPC error prints a clear message naming the path and exits non-zero, instead of stalling.

Written by the indexing model from the issue text.

Description

Summary

When the disk hosting /tmp (where rendiv writes its frame cache and bundle output) runs out of space, the render process appears to hang indefinitely — the progress counter stops advancing, no error is logged, no exit. The user has no way to tell the difference between this and a genuine deadlock or slow frame.

Reproduction

  1. Fill the disk so /tmp (or wherever rendiv writes intermediate files) has < ~50 MB free.
  2. Start a render of any non-trivial composition (rendiv render src/index.tsx MyComp out/out.mp4).
  3. Watch progress: it ticks for a while, then stalls. No error appears. The process stays alive but does no work.

In our case the host inside the container showed:

$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
overlay         886G  846G  1.2G 100% /

and the render had stalled at frame ~18011 of 30354 with ~200ms/frame shown — the counter never advanced again. There was no log output for many minutes. Killing the process and freeing disk space resolved it on retry.

Expected

When a write fails because the disk is full (ENOSPC), the renderer should:

  1. Catch the error and surface it. Print a clear message that includes the filesystem and free space, e.g.:

    ERROR: Cannot write frame 18012 — disk full (/ has 0 bytes free, needs ~2 MB per frame). Free space and re-run; partial output preserved at <path>.

  2. Exit non-zero so CI/orchestration knows the render failed.

  3. (Nice to have) Pre-flight disk check at render start. Compute a rough upper bound on disk needed (width * height * 4 bytes * estimated_keep_frames + bundle_size) and warn at startup if free space is below that threshold:

    WARNING: Render will need ~12 GB of temp space, /tmp has 1.2 GB free. Consider freeing space or pointing --temp-dir at a larger volume.

Suggested fix locations (best guess from the outside)

  • The frame-write code path that calls fs.writeFile / fs.createWriteStream on the rendered PNG / WebP per frame — wrap in try/catch and check err.code === 'ENOSPC'.
  • The bundle-write code that writes /tmp/rendiv-bundle-* and /tmp/rendiv-frames-* directories — same handling.

The silent-hang behavior strongly suggests a Promise that's awaiting a fs.writeFile that never resolves (or rejects with an unhandled error swallowed by an upstream try/catch that doesn't re-throw).

Impact

This took ~30 minutes to diagnose with no breadcrumbs. The render looked identical to other failure modes we'd hit earlier (chromium SEGV, OffthreadVideo subprocess hang, audio resolved to Infinity). A one-line error would have collapsed that diagnosis to seconds.

Environment

  • @rendiv/core: ^0.1.0
  • @rendiv/cli: ^0.1.0
  • Node: (any recent)
  • OS: Debian inside Docker container
Dominant language
TypeScript
Stars
159
Forks
32
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

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 thecodacus/rendiv

All issues in thecodacus/rendiv

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.