Document SDK embedding - #973
Conversation
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughAdds SDK navigation and overview documentation plus language-specific guides for client connections, embedded serving, native runtimes, model lifecycles, console hosting, and platform integration across Rust, Node.js/Electron, JVM/Android, and Swift. Site metadata now derives the SDK version from ChangesSDK Documentation
Estimated code review effort: 2 (Simple) | ~15 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
|
This pull request is currently a draft. Reviews will not take place until the PR is marked as ready for review. |
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (3)
website/src/docs/pages/sdk-rust.md (2)
82-84: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueUse a consistent model reference across language guides.
This example uses
unsloth/Qwen3-0.6B-GGUF:Q4_K_Mwhile the Node.js (line 80), Kotlin (line 105), and Swift (line 95) guides all useQwen2.5-3B-Instruct-Q4_K_M. Using the same model reference across guides makes cross-language comparison easier for users.♻️ Suggested change
- .model("unsloth/Qwen3-0.6B-GGUF:Q4_K_M") + .model("Qwen2.5-3B-Instruct-Q4_K_M")🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@website/src/docs/pages/sdk-rust.md` around lines 82 - 84, Update the model reference in the Rust MeshNode builder example to Qwen2.5-3B-Instruct-Q4_K_M, matching the Node.js, Kotlin, and Swift guides while leaving the surrounding builder flow unchanged.
116-118: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winConsider explicitly mentioning
ServingUnsupportedfor consistency.The overview (sdk.md line 58) instructs targets without validated local serving to surface the typed
ServingUnsupportederror. The Kotlin guide (line 126) and Swift guide (line 118) both explicitly name it. The upstream Rust FFI mapsMeshApiError::Unsupported { feature }toFfiError::ServingUnsupported. Mentioning the specific variant here would help Rust developers handle the unsupported-serving case correctly.♻️ Suggested addition
Return `MeshApiError`/`anyhow::Error` to the application boundary, report download and serving progress, and always unload a served model before shutting down when requests may still be in flight. Use an app-owned cache and avoid sharing one mutable runtime directory between concurrent nodes. + +When the host platform lacks a validated native runtime, `MeshApiError::Unsupported { feature }` surfaces as the typed `ServingUnsupported` error through the FFI layer. Handle it explicitly and show an actionable message rather than silently falling back.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@website/src/docs/pages/sdk-rust.md` around lines 116 - 118, Update the “Errors and shutdown” guidance to explicitly name the typed ServingUnsupported error for targets without validated local serving, while preserving the existing MeshApiError/anyhow::Error boundary guidance and shutdown requirements.website/src/docs/pages/sdk-node.md (1)
127-129: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winConsider explicitly mentioning the
ServingUnsupportedtyped error.The overview (sdk.md line 58) instructs targets without validated local serving to surface the typed
ServingUnsupportederror. The Kotlin guide (line 126) and Swift guide (line 118) both explicitly name it, but this section only says "serving errors" generically. Adding the specific error name would improve cross-guide consistency and help Node.js/Electron developers handle the unsupported-serving case correctly.♻️ Suggested addition
The Node API exposes `Client` for remote inference and `Node` for serving, model management, status, reconnect, and console hosting. Handle runtime resolution failures, unavailable endpoints, model download failures, and serving errors as application errors. Persist the owner keypair instead of generating a new one each time the Electron window opens. + +When the host platform lacks a validated native runtime, the SDK surfaces a `ServingUnsupported` error rather than silently falling back. Catch and surface this to the user with an actionable message.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@website/src/docs/pages/sdk-node.md` around lines 127 - 129, Update the “Runtime and errors” section to explicitly name the typed ServingUnsupported error alongside the existing serving-error guidance, preserving the current Node.js/Electron error-handling instructions.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@website/src/docs/pages/sdk-rust.md`:
- Around line 67-73: Set allow_download explicitly to false in the
NativeRuntimeInstallOptions passed to install_native_runtime, preserving the
example’s opt-in download behavior while retaining the existing defaulted
fields.
In `@website/src/docs/pages/sdk-swift.md`:
- Around line 43-44: Replace the asynchronous defer cleanup around
client.start() and the corresponding serving example with structured do/catch or
equivalent control flow that always awaits client.stop() or node.stop() before
the function exits, including when startup or serving throws. Preserve the
existing success behavior while guaranteeing cleanup completion in both
examples.
---
Nitpick comments:
In `@website/src/docs/pages/sdk-node.md`:
- Around line 127-129: Update the “Runtime and errors” section to explicitly
name the typed ServingUnsupported error alongside the existing serving-error
guidance, preserving the current Node.js/Electron error-handling instructions.
In `@website/src/docs/pages/sdk-rust.md`:
- Around line 82-84: Update the model reference in the Rust MeshNode builder
example to Qwen2.5-3B-Instruct-Q4_K_M, matching the Node.js, Kotlin, and Swift
guides while leaving the surrounding builder flow unchanged.
- Around line 116-118: Update the “Errors and shutdown” guidance to explicitly
name the typed ServingUnsupported error for targets without validated local
serving, while preserving the existing MeshApiError/anyhow::Error boundary
guidance and shutdown requirements.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 3df0c71f-5c04-4bfb-b1f7-5275c60edc24
📒 Files selected for processing (6)
website/src/_data/docs.jswebsite/src/docs/pages/sdk-kotlin.mdwebsite/src/docs/pages/sdk-node.mdwebsite/src/docs/pages/sdk-rust.mdwebsite/src/docs/pages/sdk-swift.mdwebsite/src/docs/pages/sdk.md
|
|
||
| ```swift | ||
| dependencies: [ | ||
| .package(url: "https://github.com/Mesh-LLM/mesh-llm", from: "0.72.1"), |
There was a problem hiding this comment.
@i386 hopefully people copy/pasting this don't run into old version issues - I wonder if we should have some way to generate these or have a "latest" tag here instead?
What changed
Why
The website had no SDK navigation or language-specific embedding guides, leaving application developers to reconstruct the integration flow from repository-level SDK READMEs.
Validation
just website-build✅Summary by CodeRabbit