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

ripGrep.ts records a failed grep search as a successful tool call

Open Beginner friendly
  • Is something wrong?
#29,550 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@Neal006 is already working on this.

Since Oct 16, 2026.

  • #29552 by @wyi184246-creator — closed without merging
  • #29779 by @Neal006 — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
90/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
cli, testing

Research direction

Start in packages/core/src/tools/ripGrep.ts:348-355 and compare its outer catch with packages/core/src/tools/grep.ts:323-334. Then inspect ripGrep.test.ts and the assertion at grep.test.ts:352. Done means failed ripgrep searches expose GREP_EXECUTION_ERROR through ToolResult.error and a regression test verifies that behavior.

Written by the indexing model from the issue text.

Description

area/agent status/need-triage

ripGrep.ts and grep.ts have byte-identical error handling for a failed search. One of them marks the failure; the other does not.

// packages/core/src/tools/grep.ts:323-334
    } catch (error) {
      debugLogger.warn(`Error during GrepLogic execution: ${error}`);
      const errorMessage = getErrorMessage(error);
      return {
        llmContent: `Error during grep search operation: ${errorMessage}`,
        returnDisplay: `Error: ${errorMessage}`,
        error: {
          message: errorMessage,
          type: ToolErrorType.GREP_EXECUTION_ERROR,
        },
      };
    }

// packages/core/src/tools/ripGrep.ts:348-355 — same block, no `error`
    } catch (error) {
      debugLogger.warn(`Error during GrepLogic execution: ${error}`);
      const errorMessage = getErrorMessage(error);
      return {
        llmContent: `Error during grep search operation: ${errorMessage}`,
        returnDisplay: `Error: ${errorMessage}`,
      };
    }

Why that matters. ToolResult.error is documented as "If this property is present, the tool call is considered a failure" (tools.ts:770-772), and that is exactly how it is consumed — tool-executor.ts:150 branches on toolResult.error === undefined into createSuccessResult (status: CoreToolCallStatus.Success, no error type) versus createErrorResult.

RipGrepTool is the one registered by default whenever ripgrep is available (config.ts:4028); GrepTool is only the fallback, logged as RipgrepFallbackEvent. So the unmarked path is the common one.

The most reachable way into it is a search timeout: ripGrep.ts:294 throws Operation timed out after <n>ms from inside the same outer try, and that lands in the catch above. The model is told the search failed, and the harness records the call as a success with no error type — so there is no error badge, and any accounting keyed on tool-call status counts it as a pass.

Evidence that this is an oversight, not a choice. #5688 ("fix: properly report tool errors in telemetry", merged 2025-08-08) did exactly this sweep — "Update tools to use error property in ToolResult for failures" — across read-file.ts, write-file.ts and shell.ts, and its own summary is that "tool failures were incorrectly reported as successes when tools returned errors gracefully instead of throwing exceptions". ripGrep.ts was not in that change, and grep.ts carries the field, so one of the two grep tools was converted and the other was missed.

grep.test.ts:352 pins the intended behaviour for the sibling (expect(result.error?.type).toBe(ToolErrorType.GREP_EXECUTION_ERROR)), while ripGrep.test.ts has no assertion on .error at all. ToolErrorType.GREP_EXECUTION_ERROR is used twice in grep.ts and nowhere in ripGrep.ts — and ripGrep.ts is internally inconsistent too: its inner catch at :198-201 does set error: { type: PATH_NOT_IN_WORKSPACE }.

Proposed change. Add the same error field to the ripGrep.ts catch, plus a regression test mirroring grep.test.ts:352.

I have not run this against a live ripgrep timeout — I do not have the toolchain set up to do so, and the claim above is read off the source, not observed at runtime. If you would rather it went through an issue-design discussion first, I am happy to open the PR as a draft.

Related

mcp-tool.ts:650-652 has a similar shape — a hand-rolled [Error: Could not parse tool response] string with no error field — but that one is an explicit marker for a protocol violation rather than a swallowed exception, so I have left it out of this report. It may be worth a maintainer's opinion in the same discussion.

Dominant language
TypeScript
Stars
107k
Forks
14.8k
Avg merge
1d 20h
Merged PRs (30d)
90

Getting set up

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 google-gemini/gemini-cli

All issues in google-gemini/gemini-cli

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.