fix(ipc): graceful no-op on stale paths for shell + fs handlers

[pedramamini]

Summary

Several IPC handlers reject the renderer's promise when the user supplies a path that was already removed (or that turned out to be a directory). Those callers are fire-and-forget, so the rejections surface as unhandled rejections in the renderer and Sentry captures them as bugs — even though the underlying state is routine user activity (file deleted between display and click, dropdown entry pointing at a folder, etc.).

This change mirrors the existing `shell:openPath` (MAESTRO-B3) and `fs:readFile`-ENOENT pattern so the same situations log a warning and return cleanly instead of throwing:

• `shell:showItemInFolder` → log + return when the path is gone
• `shell:trashItem` → log + return when the path is gone (user's intent already satisfied)
• `fs:readFile` → return `null` on `EISDIR` like it already does on `ENOENT`

Tests updated to cover the new behavior. No renderer changes needed; existing fire-and-forget call sites simply stop rejecting.

Sentry issues addressed

• MAESTRO-K1 — `shell:showItemInFolder` "Path does not exist"
• MAESTRO-HN — same
• MAESTRO-HS — same
• MAESTRO-JD — `shell:trashItem` "Path does not exist"
• MAESTRO-JC — same
• MAESTRO-JP — `fs:readFile` EISDIR (folder passed instead of file)

Test plan

• `npx vitest run src/tests/main/ipc/handlers/system.test.ts src/tests/main/ipc/handlers/filesystem.test.ts` — passes (146/146)
• `npm run lint:eslint` — no new errors (only pre-existing warning in unrelated `web-server-factory.ts`)
• Manual: right-click a file in the file tree, delete it from the OS, then click "Reveal in Finder" / "Move to Trash" → no toast / no Sentry capture
• Manual: pass a directory path to a file-open code path → renderer treats result as missing rather than crashing

Summary by CodeRabbit

• Bug Fixes

  • File read operations now gracefully handle attempts to read directories, returning null instead of throwing errors
  • Shell operations no longer reject when target paths don't exist; they complete gracefully with a warning log

• Tests

  • Added test coverage for directory path handling in file read operations
  • Updated tests to verify graceful completion of shell operations with missing paths

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 46512be9-91f2-41ba-aec6-553ab5a56a92

📥 Commits

Reviewing files that changed from the base of the PR and between 00be1f7 and a885bc2.

📒 Files selected for processing (4)

• src/__tests__/main/ipc/handlers/filesystem.test.ts
• src/__tests__/main/ipc/handlers/system.test.ts
• src/main/ipc/handlers/filesystem.ts
• src/main/ipc/handlers/system.ts

---

📝 Walkthrough

Walkthrough

IPC handler implementations and tests are updated to gracefully handle edge cases: file system read operations now return null for directory paths instead of throwing errors, and shell operations emit warnings and complete successfully when target paths don't exist, preventing promise rejections.

Changes

Cohort / File(s)	Summary
Filesystem IPC Handler Updates src/main/ipc/handlers/filesystem.ts, src/__tests__/main/ipc/handlers/filesystem.test.ts	fs:readFile now treats EISDIR errors as non-fatal by returning null, consistent with ENOENT behavior. Test verifies the handler resolves to null when encountering a directory path instead of rejecting.
System IPC Handler Updates src/main/ipc/handlers/system.ts, src/__tests__/main/ipc/handlers/system.test.ts	shell:trashItem and shell:showItemInFolder now detect missing absolutePath, emit Shell-scoped warnings, and return gracefully instead of rejecting. Tests verify handlers complete successfully and skip shell operations for non-existent paths.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Suggested labels

approved, ready to merge

Poem

🐰 A hop, skip, and fail with grace so fine,
No more rejections on the IPC line,
When paths disappear or directories appear,
We log and return without a fear. 🌟

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main change: graceful handling (no-op returns instead of rejections) on stale/missing paths for shell and filesystem IPC handlers.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/sentry-shell-fs-graceful-missing-paths

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[greptile-apps]

Greptile Summary

This PR converts three IPC handlers (shell:showItemInFolder, shell:trashItem, fs:readFile) from hard-throwing on stale/invalid paths to graceful no-ops, suppressing noisy unhandled rejections in the renderer for routine user-activity scenarios. The approach correctly mirrors the pre-existing shell:openPath and fs:readFile-ENOENT patterns already in the codebase.

Confidence Score: 4/5

Safe to merge; changes are narrowly scoped, well-tested, and consistent with established patterns in the codebase.

Only P2 finding (missing observability log for EISDIR in fs:readFile); no logic bugs, no security concerns, tests cover all new branches.

src/main/ipc/handlers/filesystem.ts — minor: EISDIR branch returns null silently with no log, unlike the shell handlers in this same PR.

Important Files Changed

Filename	Overview
src/main/ipc/handlers/filesystem.ts	Added EISDIR → null handling in fs:readFile to mirror existing ENOENT pattern; no log emitted on EISDIR unlike the shell handlers in this PR.
src/main/ipc/handlers/system.ts	shell:trashItem and shell:showItemInFolder now log + return on non-existent paths instead of throwing; consistent with existing shell:openPath pattern.
src/tests/main/ipc/handlers/filesystem.test.ts	New EISDIR test correctly mocks fs.readFile rejection and asserts null return; well structured.
src/tests/main/ipc/handlers/system.test.ts	Updated tests flip throw expectations to resolves.toBeUndefined() and add not.toHaveBeenCalled() assertions; thorough.

Sequence Diagram

sequenceDiagram
    participant R as Renderer
    participant IPC as IPC Handler
    participant FS as Filesystem

    Note over R,FS: shell:trashItem / shell:showItemInFolder (stale path)
    R->>IPC: invoke(handler, stalePath)
    IPC->>FS: existsSync(absolutePath)
    FS-->>IPC: false
    IPC->>IPC: logger.warn(...)
    IPC-->>R: resolves undefined (no-op)

    Note over R,FS: fs:readFile (directory path / EISDIR)
    R->>IPC: invoke('fs:readFile', dirPath)
    IPC->>FS: readFile(dirPath)
    FS-->>IPC: throws EISDIR
    IPC->>IPC: catch — error.code === 'EISDIR'
    IPC-->>R: resolves null

    Note over R,FS: fs:readFile (missing file / ENOENT) — existing behaviour
    R->>IPC: invoke('fs:readFile', missingPath)
    IPC->>FS: readFile(missingPath)
    FS-->>IPC: throws ENOENT
    IPC->>IPC: catch — error.code === 'ENOENT'
    IPC-->>R: resolves null

Loading

_{Reviews (1): Last reviewed commit: "fix(ipc): graceful no-op on stale paths ..." | Re-trigger Greptile}

[greptile-apps]

Missing observability log for EISDIR

The ENOENT branch is intentionally silent (established pattern), but EISDIR represents a different failure mode — the caller passed a directory path instead of a file path, which is a programming mistake rather than routine missing-file activity. Unlike the shell handlers in this same PR, fs:readFile returns null with no log, making it invisible in production logs when this condition fires.

Consider adding a logger.warn (or at minimum logger.debug) to match the diagnostic pattern used for shell:trashItem and shell:showItemInFolder.

Suggested change

	if (error?.code === 'EISDIR') {
	return null;
	}
	if (error?.code === 'EISDIR') {
	logger.warn(`fs:readFile - path is a directory, returning null: ${filePath}`, 'Filesystem');
	return null;
	}