BoundaryML/baml · error · io::Error

profiling store contains an unsupported file type

Error message

profiling store contains an unsupported file type

What it means

The recursive store scan only understands directories (which it recurses into), regular files (whose length it adds to the usage total), and symlinks (rejected earlier); anything else hits the else branch and raises InvalidData 'profiling store contains an unsupported file type'. This covers FIFOs, sockets, device nodes, and other non-regular entries.

Source

Thrown at baml_language/crates/bex_prof_store/src/prof/backend/store.rs:1638

                    io::ErrorKind::InvalidData,
                    "profiling store contains a symlink",
                ));
            }
            if file_type.is_dir() {
                scan(&path, root, total)?;
            } else if file_type.is_file() {
                let relative = path.strip_prefix(root).map_err(io::Error::other)?;
                if relative == Path::new("publish.lock")
                    || relative == Path::new("usage.state")
                    || relative == Path::new("tmp/usage-state.pending")
                {
                    continue;
                }
                *total = total
                    .checked_add(entry.metadata()?.len())
                    .ok_or_else(|| io::Error::other("profiling usage overflow"))?;
            } else {
                return Err(io::Error::new(
                    io::ErrorKind::InvalidData,
                    "profiling store contains an unsupported file type",
                ));
            }
        }
        Ok(())
    }

    let mut total = USAGE_STATE_BYTES;
    scan(root, root, &mut total)?;
    Ok(total)
}

fn read_usage_state(root: &Path) -> io::Result<u64> {
    let usage_state_len = usize::try_from(USAGE_STATE_BYTES).expect("fixed usage state fits usize");
    let mut bytes = Vec::with_capacity(usage_state_len);
    File::open(root.join("usage.state"))?.read_to_end(&mut bytes)?;
    if bytes.len() != usage_state_len || &bytes[..8] != USAGE_MAGIC {

View on GitHub (pinned to bd85ce9dee)

Solutions

  1. Locate the special entry (`find <store-root> ! -type f ! -type d`) and remove it.
  2. Recreate any socket/pipe the application needs in a different directory, outside the profiling store root.
  3. If the entry is required, move the profiling store root to a clean dedicated directory.
  4. Restart the store scan after cleaning; the usage accounting will then succeed.

Example fix

// shell
// before: store dir contains 'ipc.sock' (socket)
// after
rm <store-root>/ipc.sock && find <store-root> ! -type f ! -type d  # expect no output
Defensive patterns

Strategy: validation

Validate before calling

fn store_has_special_files(root: &Path) -> io::Result<bool> {
    for entry in walkdir(root) {
        let ft = entry.file_type()?;
        if !(ft.is_file() || ft.is_dir()) { return Ok(true); }
    }
    Ok(false)
}

Try / catch

match scan_store(&root) {
    Err(e) if e.kind() == io::ErrorKind::InvalidData && e.to_string().contains("unsupported file type") => {
        remove_special_entries(&root)?; // sockets, fifos, devices
        scan_store(&root)
    }
    other => other,
}

Prevention

When it happens

Trigger: Scanning a profiling store directory that contains a FIFO, unix socket, device file, or another special filesystem entry created by entry.file_type() that is neither dir, file, nor symlink.

Common situations: An in-process server created a socket inside the data directory; a test harness left a named pipe in the store path; a container/runtime mounted a device node into the store directory.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors


AI-assisted analysis of BoundaryML/baml@bd85ce9dee (2026-09-12). Data as JSON: /api/errors/0d26b2509442de63. Report an issue: GitHub.