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.

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
Defensive patterns

Strategy: retry

Validate before calling

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

Try / catch

// 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');
  }
}

Prevention

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

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

Appendix: 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)