Render hangs silently when disk is full instead of erroring

オープン
  • 何か問題がありますか？
#6 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
静か
技術スタック
docker, typescript
領域
cli

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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
主要言語
TypeScript
スター
159
フォーク
32
30日以内にマージされた PR はありません

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

thecodacus/rendiv のほかの issue

thecodacus/rendiv の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。