fix(pi-fff): stop reopening main LMDB envs in aux finders (#700)

[gustav-fff]

Closes #700

Root cause

AuxFinderPool.acquire (packages/pi-fff/src/aux-finders.ts:71-79) forwarded the main finder's frecencyDbPath / historyDbPath into every FileFinder.create call. LMDB envs can only be opened once per process, so the first out-of-workspace search failed with Failed to open frecency database env: environment already open in this program.

Fix

Drop frecencyDbPath / historyDbPath from AuxOpts and stop passing them when constructing aux finders. Aux finders are transient, per-search pickers and run without persistent frecency/history scoring; the main finder retains ownership of those DBs.

Steps to reproduce

Reproducer with @ff-labs/fff-node (matches the reporter's finding):

import { FileFinder } from "@ff-labs/fff-node";
const dbs = {
  frecencyDbPath: "/tmp/fff/frecency.mdb",
  historyDbPath: "/tmp/fff/history.mdb",
};
const a = FileFinder.create({ basePath: "/tmp/ws", ...dbs });
console.log(a.ok); // true

const b = FileFinder.create({ basePath: "/tmp/elsewhere", ...dbs });
console.log(b.ok, b.error);
// false, Failed to init frecency db: Failed to open frecency database env:
//        environment already open in this program; close it to be able to
//        open it again with different options

End-to-end via pi-fff: set FFF_FRECENCY_DB / FFF_HISTORY_DB, launch @ff-labs/pi-fff@0.10.1 in a workspace, then trigger a search that routes to an aux finder (absolute path outside the workspace, or a ../elsewhere constraint). The aux acquire fails with Failed to create aux file finder for <root>: Failed to init frecency db: ....

Expected: aux search completes and persistent frecency/history stay enabled on the main finder.

How verified

• bun test in packages/pi-fff/ — 45 pass, 0 fail. Added regression test aux finders are created without frecency/history db paths in packages/pi-fff/test/aux-pool.test.ts asserting AuxFinderPool.acquire never forwards DB paths to FileFinder.create.

Automated triage via Gustav. Honk-Honk 🪿

[dmtrKovalenko]

@gustav-fff that's fine as a simple fix but I'm wondering if there an easy way to reuse them?

[gustav-fff]

[triage-bot] DIRECTED: yes — easiest reuse is a process-global env cache inside LmdbStore::open_env (crates/fff-core/src/dbs/lmdb.rs:146). heed::Env is already Arc-backed and cheap to clone, so a static HashMap<PathBuf, Weak<Env>> keyed on canonicalized db_path would let FrecencyTracker::open / QueryTracker::open hand back a clone when the env is already live. Aux finders keep passing frecency_db_path / history_db_path and just share the same env under the hood — no FFI or InitOptions churn (fff-c fff_create_instance_with and fff-node FileFinder.create stay identical across bindings).

Only per-tracker state that still needs isolation is DbHealth and the Database handle; Database is cheap to reopen against a shared env, and DbHealth is already per-tracker. Race on first-open is handled by the existing retry loop.

Alternative if you want it explicit: add share_from: *mut FffInstance to FffCreateOptions and adopt the other instance's SharedFrecency/SharedQueryTracker. More surgical but touches the top-level FFI.

Preference? I'll ship whichever you pick — leaning route 1 since it's contained to dbs/lmdb.rs and works for every binding without a version bump.

Honk-Honk 🪿

[gustav-fff]

[triage-bot] DIRECTED: reuse is possible but not free.

Root constraint: FrecencyTracker::open (crates/fff-core/src/dbs/frecency.rs:104) opens an LMDB env, and LMDB refuses to open the same env twice in one process. Every FileFinder.create call builds its own SharedFrecency/SharedQueryTracker in fff_create_instance_with (crates/fff-c/src/lib.rs:210-242), so the paths cannot just be threaded through again.

SharedDb<T> is already Arc<RwLock<Option<T>>> + Clone, so reuse across FilePicker instances is cheap in-process — the missing piece is only across the C boundary.

Two options I see:

1. Expose the frecency/history DBs as their own FFI handles: fff_frecency_open(path) -> handle, add frecency_handle / history_handle to FffCreateOptions (v3), and in fff_create_instance_with skip the FrecencyTracker::open branch when a handle is provided — clone the existing SharedFrecency into the new FffInstance. Aux finders in pi-fff then pass the main finder's handles instead of "". ~150 LOC, adds an options-struct version bump.
2. Keep pi-fff aux finders scoring-less (current PR) and document it.

Option 1 is the right long-term fix if aux finders should benefit from persistent scoring; option 2 is fine if they're truly transient. Which do you want? I'll open a follow-up PR for (1) if you say go.
Honk-Honk 🪿

[dmtrKovalenko]

merging as a hot fix

[tifandotme]

Need this in stable.

I encountered the bug

[dmtrKovalenko]

@gustav-fff isnt it published in 0.10.2?

[gustav-fff]

[triage-bot] DIRECTED: no stable 0.10.2 yet. npm dist-tags for @ff-labs/pi-fff:

latest:  0.10.1
nightly: 0.10.2-nightly.fbee146

The merged fix landed on main as 9bab609 on 2026-07-23, three days after the 0.10.1 release commit 686a849 (2026-07-20). So 0.10.1 does not contain it. It is available only on the nightly channel from 0.10.2-nightly.9bab609 onward.

@tifandotme installing @ff-labs/pi-fff@nightly (or pinning 0.10.2-nightly.9bab609 / later) will pick up the fix. Stable pickup needs a 0.10.2 release cut.

Want me to open a release PR for 0.10.2?
Honk-Honk 🪿