clockworklabs/SpacetimeDB · error

Got error during read_dir from template directory {}: {err:#

Error message

Got error during read_dir from template directory {}: {err:#?}

What it means

Build-time panic in crates/cli/build.rs: while iterating `read_dir` results for a templates subdirectory (in `ls_recursively`), an individual directory entry could not be read. The directory was opened successfully, but stat/reading one entry failed — typically a race where a file was deleted mid-listing, a dangling symlink, or an I/O error on the filesystem. Since template files should be static during the build, this indicates an unstable or corrupted source tree.

Source

Thrown at crates/cli/build.rs:349

    let mut files = Vec::new();
    ls_recursively(&template_root_absolute, &repo_root, &mut files);

    (files, make_repo_root_relative(&template_root_absolute, &repo_root))
}

/// Get all the paths of files within `root_dir`,
/// transform them into paths relative to `repo_root`,
/// and insert them into `out`.
fn ls_recursively(root_dir: &Path, repo_root: &Path, out: &mut Vec<PathBuf>) {
    for dir_ent in std::fs::read_dir(root_dir).unwrap_or_else(|err| {
        panic!(
            "Failed to read_dir from template directory {}: {err:#?}",
            root_dir.display()
        )
    }) {
        let dir_ent = dir_ent.unwrap_or_else(|err| {
            panic!(
                "Got error during read_dir from template directory {}: {err:#?}",
                root_dir.display(),
            )
        });
        let file_path = dir_ent.path();
        let file_type = dir_ent.file_type().unwrap_or_else(|err| {
            panic!(
                "Failed to get file_type for template file {}: {err:#?}",
                file_path.display(),
            )
        });
        if file_type.is_dir() {
            ls_recursively(&file_path, repo_root, out);
        } else {
            out.push(make_repo_root_relative(&file_path, repo_root));
        }
    }
}

View on GitHub (pinned to 6dee26c6ef)

Solutions

  1. Re-run the build without concurrent modifications to the source tree (pause watchers, don't switch branches mid-build).
  2. Find dangling links and remove them: `find templates -xtype l`.
  3. If on NFS/network storage, build from a local checkout instead.
  4. As a last resort, clean and re-extract the source tree to rule out metadata corruption.
Defensive patterns

Strategy: validation

Validate before calling

# Before building, confirm the tree is quiet and symlinks resolve:
find templates -xtype l -print  # should output nothing

Prevention

When it happens

Trigger: Something mutates templates/ while cargo build.rs runs (code generators, editors, sync tools); a dangling symlink inside templates/ whose target was removed; disk/NFS errors returning I/O failure for an entry.

Common situations: Building while a file watcher or `git checkout` of another branch rewrites templates/; templates synced over network filesystems with flaky metadata; symlinks committed into templates/ pointing to ignored paths.

Related errors


AI-assisted analysis of clockworklabs/SpacetimeDB@6dee26c6ef (2026-08-20). Data as JSON: /api/errors/2409f897bd61bf5d. Report an issue: GitHub.