Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

pi-fff blocks Pi /new and /resume while waiting for FileFinder scan on session_start

Open
  • Is something wrong?
#477 4 comments 3 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

@cokekitten is already working on this.

Since May 18, 2026.

  • #478 by @cokekitten — open
  • #599 by @gustav-fff — open

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
75/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
node.js, typescript
Domain
tooling

Research direction

Start in packages/pi-fff/src/index.ts by reading the session_start handler, ensureFinder(), and the session_shutdown lifecycle. Run cd packages/pi-fff && npx tsc --noEmit, then verify that /new and /resume return without waiting for the FileFinder scan while fff operations and @-mention autocomplete can still await initialization safely.

Written by the indexing model from the issue text.

Description

triaged

Summary

@ff-labs/pi-fff currently blocks Pi session replacement (/new and /resume) because the session_start handler eagerly initializes FileFinder and awaits the initial scan.

In packages/pi-fff/src/index.ts:

pi.on("session_start", async (_event, ctx) => {
  try {
    activeCwd = ctx.cwd;
    if (shouldEnableMentions()) applyEditorMode(ctx);
    await ensureFinder(activeCwd);
  } catch (e: unknown) {
    ctx.ui.notify(...);
  }
});

ensureFinder() calls:

const result = FileFinder.create({ basePath: cwd, ... });
...
await finder.waitForScan(15000);

Because Pi recreates/reloads the session runtime when switching sessions, this means /new and selecting a session from /resume can hang until FileFinder.create() / waitForScan(15000) finishes.

Impact

  • /resume: after selecting a session, Pi appears stuck before the resumed session is usable.
  • /new: after pressing Enter, Pi appears stuck before the new session is usable.
  • This is especially noticeable in larger workspaces where scanning/watching takes non-trivial time.
  • Disabling @ff-labs/pi-fff makes /new and /resume fast again.

Expected behavior

Pi session startup should not be blocked by a file index warmup. The finder can still be warmed in the background, and actual fff tool calls / @-mention autocomplete can await the same in-flight initialization if needed.

Suggested fix

Make the session_start warmup non-blocking, e.g. schedule it after the session start event returns:

let lifecycleId = 0;

pi.on("session_start", async (_event, ctx) => {
  try {
    activeCwd = ctx.cwd;
    const sessionLifecycleId = ++lifecycleId;
    if (shouldEnableMentions()) applyEditorMode(ctx);

    setTimeout(() => {
      if (sessionLifecycleId !== lifecycleId) return;
      ensureFinder(activeCwd).catch((e: unknown) => {
        if (sessionLifecycleId !== lifecycleId) return;
        ctx.ui.notify(
          `FFF init failed: ${e instanceof Error ? e.message : String(e)}`,
          "error",
        );
      });
    }, 0);
  } catch (e: unknown) {
    ctx.ui.notify(
      `FFF init failed: ${e instanceof Error ? e.message : String(e)}`,
      "error",
    );
  }
});

pi.on("session_shutdown", async () => {
  lifecycleId++;
  destroyFinder();
});

I also found it safer for ensureFinder() to return the local createdFinder after waitForScan() rather than the mutable global finder, so a shutdown during warmup cannot accidentally return a destroyed/replaced finder.

Local validation

I tested a local patch with:

cd packages/pi-fff
npx tsc --noEmit

and verified that importing the extension still returns a valid factory. With the patch, /new and /resume are no longer blocked by the scan warmup; the first actual fff operation may still await initialization, which seems like the expected tradeoff.

Related issues I found

I did not find an exact duplicate for pi-fff blocking Pi /new or /resume. Some related pi-fff/watcher issues:

  • #403: parallel ffgrep calls and ensureFinder singleton synchronization
  • #439: aiMode: true watcher file descriptor usage on macOS
  • #476: macOS segfault while watching directories during clone operations

This issue seems specifically about lifecycle behavior in the Pi extension: doing blocking index warmup inside session_start.

Environment

  • @ff-labs/pi-fff: 0.8.1
  • Pi: 0.75.1
  • Node.js: v24.13.1
  • OS: macOS / Darwin arm64
Dominant language
Rust
Stars
11.2k
Forks
467
Avg merge
2d 4h
Merged PRs (30d)
34

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from dmtrKovalenko/fff

All issues in dmtrKovalenko/fff

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.