BoundaryML/baml · error

profiling store is in use: {}

Error message

profiling store is in use: {}

What it means

`baml clean` deletes the segmented profiler data store, but the backend refuses when the profiling store is currently in use (CleanProfilesError::InUse). The command bails with the profiles root path so you know which store is busy.

Source

Thrown at baml_language/crates/baml_cli/src/clean_command.rs:36

        let project_root = crate::project_load::find_project_root_from(self.from.as_deref())?
            .unwrap_or(std::env::current_dir().context("failed to resolve current directory")?);
        // Same resolution rule as the producer and `baml query`:
        // BAML_PROFILE_DIR wins, else the project store. Resolving this
        // differently would report "Clean" while leaving recorded data in
        // the directory the profiler actually wrote to.
        let profiles_root =
            bex_events::prof::backend::ProfilerSession::resolve_store_root(&project_root);
        match bex_events::prof::backend::clean_profiles_v1(&profiles_root) {
            Ok(removed) => {
                let reporter = crate::reporter::Reporter::new();
                reporter.status(
                    if removed { "Removed" } else { "Clean" },
                    profiles_root.display().to_string(),
                );
                Ok(crate::ExitCode::Success)
            }
            Err(bex_events::prof::backend::CleanProfilesError::InUse) => {
                bail!("profiling store is in use: {}", profiles_root.display())
            }
            // Cleanup refuses any root not shaped `.../.baml/profiles-v1`,
            // so it cannot delete an arbitrary BAML_PROFILE_DIR. Say so
            // instead of surfacing the bare `InvalidRoot`.
            Err(bex_events::prof::backend::CleanProfilesError::InvalidRoot)
                if std::env::var_os("BAML_PROFILE_DIR").is_some() =>
            {
                bail!(
                    "BAML_PROFILE_DIR points at {}, which is not a `.baml/profiles-v1` store; \
                     remove it manually",
                    profiles_root.display()
                )
            }
            Err(error) => Err(anyhow::Error::new(error).context(format!(
                "failed to clean segmented profiler data at {}",
                profiles_root.display()
            ))),
        }

View on GitHub (pinned to bd85ce9dee)

Solutions

1. Stop the running baml process (dev server, test run) that is writing profile data, then re-run clean.
2. Check for orphaned baml processes (ps aux | grep baml) and kill them before cleaning.
3. If a crashed process left the lock, remove the store manually: rm -rf <project>/.baml/profiles-v1.

Example fix

# before
baml clean  # fails while `baml dev` is running
# after
# stop baml dev first, then:
baml clean

// shell: ensure no baml process holds the store before cleaning
pgrep -f 'baml (dev|test)' && echo "stop running baml processes first" || baml clean

// retry after stopping writers
try {
  await run('baml clean');
} catch (e) {
  if (String(e).includes('profiling store is in use')) {
    await stopBamlProcesses();
    await run('baml clean');
  }
}

When it happens

Trigger: Running `baml clean` (or clean --profiles) while another baml process holds the profiling store open — e.g. a concurrent `baml dev` session actively writing profiles under `.../.baml/profiles-v1`.

Common situations: Trying to clean profiles while a dev server or test run with BAML_PROFILING enabled is still running; leftover lock from a crashed process still holding the store.

Related errors

• BAML_PROFILE_DIR points at {}, which is not a `.baml/profile
• failed to clean segmented profiler data at {}
• usage: baml self-update unexpected arguments: {}
• usage: baml toolchain install <canary|nightly|version>
• usage: baml toolchain use <canary|nightly|version|path>

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