[Bug]: grep timeBudgetMs is ignored for zero-match searches

[henrychu04]

Which fff frontend?

Node SDK (@ff-labs/fff-node)

has logs

No response

Description

Summary

FileFinder.grep() does not enforce timeBudgetMs when a plain-text search produces no matches.

In the reproduction below, a 5 ms search scans all 10,000 candidate files, returns nextCursor: null, and takes substantially longer than the requested budget.

Because the Node API is synchronous and exposes no cancellation mechanism, callers cannot independently interrupt the native operation. This makes timeBudgetMs the only available execution bound.

Environment

• Linux x86-64
• Node.js 24
• Reproduced with @ff-labs/fff-node 0.9.4
• The relevant condition appears unchanged in the 0.10.5 source:
  https://github.com/dmtrKovalenko/fff/blob/v0.10.5/crates/fff-core/src/grep/grep.rs

Reproduction

mkdir fff-budget-repro
cd fff-budget-repro
npm init -y
npm install @ff-labs/fff-node@0.10.5

Save the following as repro.mjs:

import * as fs from "node:fs/promises";
import * as os from "node:os";
import * as path from "node:path";
import { FileFinder } from "@ff-labs/fff-node";

function unwrap(result) {
  if (!result.ok) {
    throw new Error(`FFF operation failed: ${result.error}`);
  }
  return result.value;
}

const root = await fs.mkdtemp(
  path.join(os.tmpdir(), "fff-no-match-budget-"),
);

let finder;

try {
  const contents = `${"x".repeat(4 * 1024)}\n`;

  for (let batch = 0; batch < 100; batch += 1) {
    await Promise.all(
      Array.from({ length: 100 }, (_, index) =>
        fs.writeFile(
          path.join(root, `${batch}-${index}.txt`),
          contents,
        ),
      ),
    );
  }

  finder = unwrap(
    FileFinder.create({
      basePath: root,
      disableMmapCache: true,
      disableContentIndexing: false,
      aiMode: false,
      enableFsRootScanning: false,
      enableHomeDirScanning: false,
    }),
  );

  const ready = unwrap(await finder.waitForIndexReady(30_000));
  if (!ready) {
    throw new Error("Index did not become ready");
  }

  const startedAt = performance.now();

  const result = unwrap(
    finder.grep("needle-not-present", {
      mode: "plain",
      maxFileSize: 1024 * 1024,
      pageSize: 500,
      timeBudgetMs: 5,
    }),
  );

  const elapsedMs = performance.now() - startedAt;

  console.log({
    elapsedMs,
    totalFiles: result.totalFiles,
    filteredFileCount: result.filteredFileCount,
    totalFilesSearched: result.totalFilesSearched,
    nextCursor: result.nextCursor,
    cancellationAvailable: "cancel" in finder,
  });
} finally {
  finder?.destroy();
  await fs.rm(root, { recursive: true, force: true });
}

Run:

node repro.mjs

Actual behavior

Example result from Linux x86-64:

{
  elapsedMs: 59.25,
  totalFiles: 10000,
  filteredFileCount: 10000,
  totalFilesSearched: 10000,
  nextCursor: null,
  cancellationAvailable: false
}

The exact elapsed time is hardware-dependent, but the important behavior is that all candidate files are searched and no continuation cursor is returned after the time budget expires.

Expected behavior

When timeBudgetMs expires:

• Grep should stop traversing candidate files even if it has found zero matches.
• totalFilesSearched should be less than filteredFileCount.
• nextCursor should allow the caller to resume from the next unsearched file, or the result should otherwise explicitly indicate that the search timed out.
• The synchronous native call should return within a small, documented amount of overshoot beyond the requested budget.

Suspected root cause

The plain/regex grep budget check is conditional on existing matches:

if !need_abort
    && let Some(budget) = time_budget
    && all_matches.len() > 1
    && search_start.elapsed() > budget
{
    need_abort = true;
}

For a zero-match search, all_matches.len() remains zero, so the deadline condition is never applied.

Removing the match-count condition, while preserving cursor accounting for the partially consumed chunk, appears necessary.

Relationship to #746 / #750

This is related to, but not resolved by:

• [Bug]: broad absolute home-path ffgrep can appear to hang without returning a result #746
• fix(pi-fff): dedup concurrent aux finders and bound grep time (#746) #750

PR #750 added timeBudgetMs to the pi-fff wrapper and deduplicated auxiliary index creation. It did not address the native zero-match budget bypass demonstrated here.

[gustav-fff]

[triage-bot] REPRODUCED: Reproduced on origin/main. Branch: triage-bot/issue-826.

Root cause is as you diagnosed, plus a second one downstream. crates/fff-core/src/grep/grep.rs:610 gates the deadline on all_matches.len() > 1, so zero-match searches never abort. Even with that gate removed, crates/fff-core/src/grep/grep.rs:682-684 unconditionally overwrites files_consumed = files_to_search.len() whenever result_files is empty, which forces next_file_offset = 0. So the cursor would still be lost. Same pattern exists in the fuzzy path at crates/fff-core/src/grep/types.rs:218-220.

Repro without Node, straight against the Rust core (crates/fff-core/tests/repro_826.rs, 10k files x 4KiB, time_budget_ms: 5, page_limit: 500, plain mode):

$ cargo test -p fff-search --test repro_826 --release
elapsed_ms=111.93 total_files=10000 filtered_file_count=10000 total_files_searched=10000 next_file_offset=0

thread 'zero_match_search_respects_time_budget' panicked at crates/fff-core/tests/repro_826.rs:65:5:
budget expired but all 10000 candidate files were searched

5ms requested, 111.93ms spent, entire candidate set scanned, no resume cursor. Matches your Linux numbers.

Working on fix on triage-bot/issue-826.

Honk-Honk 🪿

[dmtrKovalenko]

I feel like this is going to break the existing customers, there was always a premise that we start counting budget only after the first found cause if we didn't find anything there is no way to resume the dialog. I think there should be more sense in storing a configuration option like enforceTimeBudget that will enforce it when there is no matches.

Cause I think there is more harm in longer response time than not highlighting a single match in the very last page of files

[dmtrKovalenko]

@gustav-fff read my comment and update your PR accordingly

[dmtrKovalenko]

@gustav-fff hello?

[gustav-fff]

[triage-bot] DIRECTED: Done, #827 updated to your call. Flag, not a behaviour change.

GrepSearchOptions.enforce_time_budget, default false. Off = the old rule (crates/fff-core/src/grep/grep.rs:600 keeps all_matches.len() > 1), so a zero-match query still full-scans. On = hard bound with a working resume cursor.

Surfaces: enforceTimeBudget (node/bun), grep.enforce_time_budget (nvim config + content_search opt), enforce_time_budget= (python). C ABI is untouched — fff_live_grep/fff_multi_grep keep their exact signatures and forward false; the flag lives on new fff_live_grep_ex/fff_multi_grep_ex. Appending a 13th arg would have broken the frozen ABI, so _ex pair instead. @dmtrKovalenko flagging that, it is the one non-obvious bit.

Two things stay unconditional because they are bugs, not policy:

• files_consumed was overwritten with files_to_search.len() on any zero-match page, so an aborted page lied about its progress and dropped the cursor. Fixed for both plain and fuzzy paths.
• an abort now never skips file 0 — next_file_offset == 0 reads as "done" to every caller, so paging would stall.

Fuzzy grep already enforced the budget with zero matches. Left as-is, flag only touches plain/regex.

Regression guard for exactly your concern, zero_match_search_ignores_unenforced_time_budget:

$ cargo test -p fff-search --test grep_time_budget_zero_match --release
test zero_match_fuzzy_search_stops_at_time_budget ... ok
test zero_match_search_ignores_unenforced_time_budget ... ok
test zero_match_search_stops_at_enforced_time_budget ... ok
test budget_resume_cursor_does_not_skip_files ... ok

test result: ok. 4 passed; 0 failed

No per-file cost: the gate folds into the Option<Duration> before the rayon par_iter.

Honk-Honk 🪿