refactor(electron): implement robust IPC error handling and full test coverage

[Shevilll]

Summary

This pull request implements robust IPC error handling, prevents potential memory leaks in the main process, and introduces full unit test coverage for the IPC modules.

Changes

1. Main Process IPC (src/ipc/main.ts)

   • Added checking of webContents.isDestroyed() before sending any messages to avoid crashes.
   • Replaced .once() with .on() combined with manual cleanup on any resolution path.
   • Added a listener on the destroyed event of webContents to clean up the ipcMain response channel listener if the window is closed/destroyed while waiting for a response, resolving a potential listener leak.
   • Wrapped webContents.send in a try-catch block to clean up listeners and reject the promise cleanly on error.

2. Renderer Process IPC (src/ipc/renderer.ts)

   • Improved error serialization inside handle so that non-Error exceptions (such as custom objects or string errors) are successfully serialized and sent back to the main process, preventing hanging promises in the main process.

3. Unit Tests Coverage

   • Added src/ipc/main.spec.ts testing main-process invoke and handle with strict edge cases (webContents destruction, destroyed-during-wait, handler registration and cleanup, throw-on-send, error resolution/rejection).
   • Added src/ipc/renderer.spec.ts testing renderer handle (success, Error serialization, string-error serialization), invoke, and retry logic (invokeWithRetry).

Verification

All existing and new test suites compile and pass successfully under the Electron simulation runner:

• Total passed tests: 300 across 23 test suites.
• Code successfully builds and compiles.

[coderabbitai]

Warning

Review limit reached

@Shevilll, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 35 minutes and 16 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 49ceb3cf-1522-47cf-bb4d-22c4933dac84

📥 Commits

Reviewing files that changed from the base of the PR and between 652b374 and b25676a.

📒 Files selected for processing (6)

• src/ipc/main.spec.ts
• src/ipc/main.ts
• src/ipc/renderer.spec.ts
• src/ipc/renderer.ts
• src/ui/main/rootWindow.spec.ts
• src/ui/main/rootWindow.ts

---

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.}