Skip to content

docs: add comprehensive docstrings to ipc_common module#24

Merged
wilcorrea merged 1 commit into
mainfrom
docs/ipc-common-docstrings
Feb 25, 2026
Merged

docs: add comprehensive docstrings to ipc_common module#24
wilcorrea merged 1 commit into
mainfrom
docs/ipc-common-docstrings

Conversation

@iguit0

@iguit0 iguit0 commented Feb 25, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Adds module-level, struct-level, field-level, and function-level Rust docstrings to  ipc_common.rs 
  • Brings documentation coverage from ~33% to 100%, exceeding the 80% threshold flagged by CodeRabbit

What’s documented

  • Module-level  //!  block: Purpose, wire protocol (newline-delimited JSON), supported commands table, platform compatibility notes
  • IpcCommand  struct + fields: JSON examples, field descriptions (command name, optional path)
  • IpcResponse  struct + fields: JSON examples, success/error semantics, serialization behavior
  • process_command()  function: All three command variants ( open ,  ping ,  show ), parameters, return value, and error cases

Test plan

  • Verify  cargo doc  generates the expected documentation
  • Confirm CodeRabbit docstring coverage check passes (≥80%)

Closes #18

Summary by CodeRabbit

  • New Features
    • Enabled inter-process communication system supporting file operations, window management, and application commands
    • Added robust error handling for invalid file paths and missing resources
    • Implemented command processing for seamless operation handling

Add module-level, struct-level, field-level, and function-level
documentation to ipc_common.rs to meet the 80% docstring coverage
threshold flagged by CodeRabbit.

Documents the wire protocol (newline-delimited JSON), all three
supported IPC commands (open, ping, show), platform compatibility
notes, and JSON examples for both IpcCommand and IpcResponse.

Closes #18
@iguit0 iguit0 requested a review from wilcorrea February 25, 2026 04:45
@coderabbitai

coderabbitai Bot commented Feb 25, 2026

Copy link
Copy Markdown
📝 Walkthrough

Walkthrough

This change introduces a public IPC command system in the ipc_common.rs module by exposing IpcCommand and IpcResponse structures alongside a process_command() function. The implementation handles three commands ("open", "ping", "show") with associated behaviors including path canonicalization, window focus management, and event emission.

Changes

Cohort / File(s) Summary
Shared IPC Command System
apps/tauri/src-tauri/src/ipc_common.rs
Added public IpcCommand struct with command and optional path fields, public IpcResponse struct with success flag and optional error message, and public process_command() function that dispatches "open", "ping", and "show" commands with path canonicalization, window focus management, and error handling.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Possibly related issues

Possibly related PRs

Poem

🐰 A shared IPC path now gleams so bright,
With commands hopping left and right,
Public structs that talk and play,
Processes ping throughout the day!
Thump thump goes the dev's delight! 🎉

🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (2 warnings)

Check name Status Explanation Resolution
Title check ⚠️ Warning The PR title states it adds docstrings, but the actual changes include new public API structures (IpcCommand, IpcResponse, process_command function) beyond documentation. Update the title to reflect the full scope of changes, such as 'feat: add IPC command processing API with comprehensive docstrings' or 'refactor: expose shared IPC API with documentation'.
Out of Scope Changes check ⚠️ Warning The PR introduces new public API structures (IpcCommand, IpcResponse, process_command) that appear to be code changes beyond the documentation-only scope stated in the PR objectives. Clarify whether publicizing the IPC API is intentional. If so, update PR title and objectives to reflect API exposure; if not, separate API changes into a distinct PR.
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Linked Issues check ✅ Passed The PR implements all documented requirements from issue #18: module-level docs, struct documentation, function documentation, and docstring coverage improvement to meet 80% threshold.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

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

✨ Finishing Touches
  • 📝 Generate docstrings (stacked PR)
  • 📝 Generate docstrings (commit on current branch)
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch docs/ipc-common-docstrings

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

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

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)
apps/tauri/src-tauri/src/ipc_common.rs (2)

111-111: ⚠️ Potential issue | 🟡 Minor

std::fs::canonicalize fails on non-existent paths — doc and error message could be misleading.

std::fs::canonicalize requires the path to already exist on the filesystem (it resolves symlinks and calls realpath/GetFullPathName under the hood). If a caller passes a syntactically valid but non-existent path, the OS error returned is NotFound, yet the response surfaces as "Invalid path: {e}" — which implies the path string itself is malformed rather than absent.

Two related gaps:

  1. The process_command doc (line 89) says "invalid" path but doesn't note the existence requirement imposed by canonicalize.
  2. The error message "Invalid path: …" conflates "path doesn't exist" with "path is syntactically invalid".

Consider distinguishing the two cases or updating the doc to call out the existence requirement:

💡 Suggested improvement
                     Err(e) => IpcResponse {
                         success: false,
-                        error: Some(format!("Invalid path: {}", e)),
+                        error: Some(format!("Path not found or inaccessible: {}", e)),
                     },

And in the docstring:

-/// Returns an error if the path is missing, invalid, or the event
-/// fails to emit.
+/// Returns an error if the path field is absent, the path does not exist on
+/// disk (or is otherwise inaccessible to `std::fs::canonicalize`), or the
+/// event fails to emit.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@apps/tauri/src-tauri/src/ipc_common.rs` at line 111, Update the
process_command documentation to state that std::fs::canonicalize requires the
path to exist (it resolves symlinks/real paths) and then change the canonicalize
error handling in the match where std::fs::canonicalize(&path) is called: detect
io::ErrorKind::NotFound and return an explicit "path does not exist" error
message, while preserving a separate "invalid path" or generic message for other
error kinds; reference the process_command docstring and the canonicalize match
branch to make the two cases distinct.

148-158: ⚠️ Potential issue | 🟡 Minor

show silently no-ops and returns success: true when the main window is absent.

If get_webview_window("main") returns None (e.g., during app teardown or if the window label changes), the show command does nothing at all yet still reports success. The doc accurately says "Always returns success: true", but the behavior is a silent no-op that callers cannot distinguish from a genuine window-focus operation.

The same pattern exists in the open branch (lines 115–119): window focus is silently skipped if the window isn't found, yet the open-file event is still emitted — which could cause the frontend to try to open a file in a hidden/minimized window.

Consider returning an error (or at minimum logging a warning) when the window cannot be found:

💡 Suggested improvement for `show`
         "show" => {
-            if let Some(window) = app.get_webview_window("main") {
-                let _ = window.unminimize();
-                let _ = window.show();
-                let _ = window.set_focus();
+            match app.get_webview_window("main") {
+                Some(window) => {
+                    let _ = window.unminimize();
+                    let _ = window.show();
+                    let _ = window.set_focus();
+                }
+                None => {
+                    return IpcResponse {
+                        success: false,
+                        error: Some("Main window not found".to_string()),
+                    };
+                }
             }
             IpcResponse {
                 success: true,
                 error: None,
             }
         }
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@apps/tauri/src-tauri/src/ipc_common.rs` around lines 148 - 158, The "show"
branch currently silently no-ops and returns IpcResponse { success: true } when
app.get_webview_window("main") is None; change this so that when
get_webview_window("main") returns None you either return IpcResponse with
success: false and an explanatory error message or at minimum log a warning
before returning success=false; update the same pattern in the "open" branch
(where the open-file event is emitted) to detect a missing window and return an
error/log instead of proceeding silently. Locate the branches using
get_webview_window("main") and the IpcResponse construction to implement the
check and adjust return values/messages accordingly.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Outside diff comments:
In `@apps/tauri/src-tauri/src/ipc_common.rs`:
- Line 111: Update the process_command documentation to state that
std::fs::canonicalize requires the path to exist (it resolves symlinks/real
paths) and then change the canonicalize error handling in the match where
std::fs::canonicalize(&path) is called: detect io::ErrorKind::NotFound and
return an explicit "path does not exist" error message, while preserving a
separate "invalid path" or generic message for other error kinds; reference the
process_command docstring and the canonicalize match branch to make the two
cases distinct.
- Around line 148-158: The "show" branch currently silently no-ops and returns
IpcResponse { success: true } when app.get_webview_window("main") is None;
change this so that when get_webview_window("main") returns None you either
return IpcResponse with success: false and an explanatory error message or at
minimum log a warning before returning success=false; update the same pattern in
the "open" branch (where the open-file event is emitted) to detect a missing
window and return an error/log instead of proceeding silently. Locate the
branches using get_webview_window("main") and the IpcResponse construction to
implement the check and adjust return values/messages accordingly.

ℹ️ Review info

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between a218d4b and 815adeb.

📒 Files selected for processing (1)
  • apps/tauri/src-tauri/src/ipc_common.rs

@wilcorrea wilcorrea merged commit c33a952 into main Feb 25, 2026
1 check passed
@wilcorrea wilcorrea deleted the docs/ipc-common-docstrings branch February 25, 2026 08:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

docs: Add docstrings to ipc_common module

2 participants