feat(vscode): template gallery sidebar + auto-open starter pipeline on first install#548
feat(vscode): template gallery sidebar + auto-open starter pipeline on first install#548
Conversation
… scraper RAG, audio transcription, multi-agent
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds five new flow templates to shared UI JSON, a Templates tree view and create command in the VS Code extension, a SidebarTemplatesProvider that scaffolds .pipe files (including a starter pipeline), an initial auto-layout trigger in FlowCanvas, legacy node position handling in graph parsing, and theme token/shadow updates. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Sidebar as SidebarTemplatesProvider
participant FS as VSCode FileSystem
participant Editor as PageEditor
participant Logger
User->>Sidebar: open Templates view / invoke create
Sidebar->>User: show QuickPick (template) and QuickPick(s) for requirements
User-->>Sidebar: select template and provider options
Sidebar->>FS: write generated .pipe JSON (with project_id) to workspace
FS-->>Sidebar: success / error
Sidebar->>Editor: open created .pipe in PageEditor (after delay)
Sidebar->>Logger: log warnings/errors if scaffold fails
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/shared-ui/src/modules/flow/templates/templates.json`:
- Around line 181-248: The template references a component "tool_firecrawl_1"
(provider "tool_firecrawl") but that provider has no output lanes while
"preprocessor_langchain_1" expects a "text" lane; fix by updating the provider
definition for "tool_firecrawl" to include an output lane named "text" (or
rename/change the lane used by "preprocessor_langchain_1" to match an existing
output), ensuring the component id "tool_firecrawl_1" emits "text" and the input
mapping on "preprocessor_langchain_1" uses that same lane.
- Around line 302-348: The template currently wires agent_rocketride_2 to
receive questions from chat_1 but never connects its answers output to the
response handler (response_answers_1), causing ambiguity; either document that
agent_rocketride_2 is a supporting/worker agent (add an inline comment near
agent_rocketride_2 explaining its role relative to agent_rocketride_1) or wire
its answers lane to the response handler (add an input entry from
agent_rocketride_2 to response_answers_1) so both agents’ outputs feed
response_answers_1; ensure alignment with the answers lane defined for the
agent_rocketride provider in services.json.
- Around line 249-276: The template wires webhook_1's "tags" lane into
audio_transcribe_1 but audio_transcribe only accepts "audio" or "video"; update
the input for the component with id "audio_transcribe_1" so its input array uses
lane "audio" (or "video") from "webhook_1" instead of "tags" (i.e., change the
input entry for audio_transcribe_1 to reference lane "audio" or "video" and from
"webhook_1"), leaving the response_text_1 connection to audio_transcribe_1
unchanged.
🪄 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: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: e919a571-0f86-4ec8-a758-6d0cb267b45e
📒 Files selected for processing (1)
packages/shared-ui/src/modules/flow/templates/templates.json
…ates sidebar On first activation (welcome not dismissed), create getting-started.pipe from RAG Chat template with default providers (chroma + llm_openai) and open it in the custom editor. Add Templates TreeView in the explorer sidebar listing all 8 pipeline templates. Clicking a template shows QuickPicks for required provider slots (vector store, LLM), creates the .pipe file, and opens it.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@apps/vscode/src/providers/SidebarTemplatesProvider.ts`:
- Around line 44-64: Replace the hard-coded provider and template lists in
SidebarTemplatesProvider (e.g., STORE_PROVIDERS, LLM_PROVIDERS, PROVIDER_OPTIONS
and the template catalog at lines ~67-354) with imports from a new/shared typed
module; create or reuse a shared module that exports the typed ProviderOption
and the canonical arrays (storeProviders, llmProviders, providerOptions, and the
template catalog), update SidebarTemplatesProvider to import those symbols and
remove the local definitions so both the empty-canvas picker and VS Code
Templates view consume the same source of truth, and update any references to
the renamed exports accordingly.
- Around line 474-489: The template file creation uses
vscode.Uri.joinPath(workspaceFolder.uri, fileName) which ignores the configured
rocketride.defaultPipelinePath; change the destination resolution to include the
configured pipeline directory (e.g. resolve a defaultPipelinePath string from
configuration and call vscode.Uri.joinPath(workspaceFolder.uri,
defaultPipelinePath, fileName)) when computing fileUri (the same logic used by
the normal create-file flow), apply the same change to the duplicate creation
block around the 511-537 region, and then write the fileUri via
vscode.workspace.fs.writeFile as before.
🪄 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: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 5f45df7b-1fc1-41e2-847f-1cff9ec258a4
📒 Files selected for processing (3)
apps/vscode/package.jsonapps/vscode/src/extension.tsapps/vscode/src/providers/SidebarTemplatesProvider.ts
… improve contrast
…, honor defaultPipelinePath
There was a problem hiding this comment.
Actionable comments posted: 4
♻️ Duplicate comments (5)
apps/vscode/src/providers/SidebarTemplatesProvider.ts (4)
44-64: 🧹 Nitpick | 🔵 TrivialDuplicate source of truth for provider options.
These provider lists are hard-coded here but likely exist elsewhere in the codebase (e.g., services metadata or shared-ui). Changes to available providers would need to be synchronized manually.
Consider importing from a shared module or deriving from the services catalog at runtime.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/vscode/src/providers/SidebarTemplatesProvider.ts` around lines 44 - 64, The hard-coded provider arrays STORE_PROVIDERS, LLM_PROVIDERS and the PROVIDER_OPTIONS map duplicate a source of truth; replace them by importing or deriving the provider lists from the shared metadata/service catalog module (e.g., the central providers list in shared-ui or services metadata) so updates are managed in one place—modify SidebarTemplatesProvider to import the canonical provider data and build PROVIDER_OPTIONS from that import instead of defining STORE_PROVIDERS/LLM_PROVIDERS inline.
473-487:⚠️ Potential issue | 🟠 MajorTemplate files ignore
rocketride.defaultPipelinePathconfiguration.Files are created directly in the workspace root (
workspaceFolder.uri), but the extension has arocketride.defaultPipelinePathsetting (default:${workspaceFolder}/pipelines). Template-created files will land outside the configured pipeline directory and may not appear in the Pipelines tree.♻️ Suggested fix
+ // Resolve the configured pipeline directory + const config = vscode.workspace.getConfiguration('rocketride'); + const defaultPath = config.get<string>('defaultPipelinePath') || 'pipelines'; + const pipelineDir = vscode.Uri.joinPath(workspaceFolder.uri, defaultPath.replace('${workspaceFolder}/', '')); + + // Ensure directory exists + try { + await vscode.workspace.fs.createDirectory(pipelineDir); + } catch { + // Directory may already exist + } + // Find a unique filename let fileName = `${slug}.pipe`; let counter = 1; - let fileUri = vscode.Uri.joinPath(workspaceFolder.uri, fileName); + let fileUri = vscode.Uri.joinPath(pipelineDir, fileName); for (;;) { try { await vscode.workspace.fs.stat(fileUri); // File exists, try next counter++; fileName = `${slug}-${counter}.pipe`; - fileUri = vscode.Uri.joinPath(workspaceFolder.uri, fileName); + fileUri = vscode.Uri.joinPath(pipelineDir, fileName);🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/vscode/src/providers/SidebarTemplatesProvider.ts` around lines 473 - 487, The template creation currently always writes to workspaceFolder.uri; update the logic in SidebarTemplatesProvider that computes fileName/fileUri (symbols: fileName, fileUri, workspaceFolder, slug) to honor the rocketride.defaultPipelinePath setting: read the configured path via vscode.workspace.getConfiguration('rocketride').get('defaultPipelinePath', 'pipelines'), resolve it against workspaceFolder.uri using vscode.Uri.joinPath to produce a targetDirUri, ensure the directory exists (create if needed), and then use targetDirUri when creating the unique fileUri loop instead of workspaceFolder.uri so new .pipe files land in the configured pipelines folder.
507-544:⚠️ Potential issue | 🟠 Major
scaffoldStarterPipelinealso ignoresdefaultPipelinePath.Same issue as the template create command —
getting-started.pipeis written to the workspace root rather than the configured pipeline directory.Apply the same fix pattern here at line 511.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/vscode/src/providers/SidebarTemplatesProvider.ts` around lines 507 - 544, The scaffoldStarterPipeline function currently writes getting-started.pipe into the workspace root and should respect the configured defaultPipelinePath; update how starterFile is built by using the same pipeline directory resolution as the template create command (read the defaultPipelinePath setting or computed pipelineDir for the workspace) instead of joining directly to workspaceFolder.uri, ensure the target directory exists (create it if needed) and then write/open the file; key symbols to update: scaffoldStarterPipeline, starterFile, and the logic that constructs the file Uri so it uses the configured pipeline directory rather than the workspace root.
91-354: 🧹 Nitpick | 🔵 TrivialDuplicate template catalog creates maintenance burden.
This entire
TEMPLATESobject duplicatespackages/shared-ui/src/modules/flow/templates/templates.json. The comment on line 67 acknowledges this ("hard-coded from shared-ui/templates.json"), but any template changes must now be made in two places.Consider either:
- Importing the templates JSON directly (may require bundler configuration)
- Creating a shared TypeScript module that both locations consume
- Generating this file from templates.json at build time
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/vscode/src/providers/SidebarTemplatesProvider.ts` around lines 91 - 354, The hard-coded TEMPLATES object duplicates the canonical templates in shared-ui and should be replaced by a single source of truth; remove the TEMPLATES constant in SidebarTemplatesProvider.ts and instead import the JSON (or a shared TS module) from the shared-ui templates (e.g. import templates from 'packages/shared-ui/src/modules/flow/templates/templates.json' or from a new shared module), ensure the imported type aligns with TemplateInfo (or export the type from the shared module), and update any code that references TEMPLATES to use the imported templates—if your bundler disallows raw JSON imports, create/export a shared TypeScript module (e.g. templates.ts) in shared-ui and import that here or add a build step to generate this file from templates.json.packages/shared-ui/src/modules/flow/templates/templates.json (1)
277-350: 🧹 Nitpick | 🔵 TrivialClarify the role of
agent_rocketride_2in the multi-agent architecture.Both agents receive questions from
chat_1, but onlyagent_rocketride_1feeds intoresponse_answers_1(line 346). Theagent_rocketride_2outputs are not connected to any response handler.If this is intentional (e.g., agent_2 is a worker that supports agent_1 via shared memory), consider adding a
descriptionornamefield to the component to document its role. Otherwise, users may be confused about why one agent's output isn't captured.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/shared-ui/src/modules/flow/templates/templates.json` around lines 277 - 350, The multi-agent template currently sends input from chat_1 to both agent_rocketride_1 and agent_rocketride_2 but only wires agent_rocketride_1 to response_answers_1, leaving agent_rocketride_2 outputs unused; either explicitly document agent_rocketride_2's role (e.g., add a "name" or "description" field like "assistant/worker: supports agent_rocketride_1 via shared memory" on the agent_rocketride_2 component and mention memory_internal_1 as shared memory), or wire agent_rocketride_2 outputs to an appropriate response handler (e.g., add an input mapping from agent_rocketride_2 to response_answers_1 or add a new response component) so users can see its outputs.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@apps/vscode/src/providers/SidebarTemplatesProvider.ts`:
- Around line 484-486: Replace the empty catch in the name-existence loop with
an explicit error handler: change the catch to capture the error (catch (err)),
check for vscode.FileSystemError with code 'FileNotFound' and only treat that as
the expected branch (break to accept the name); for any other error re-throw it
so permission or unexpected filesystem errors in SidebarTemplatesProvider (the
loop that checks candidate template names) are not silently swallowed.
- Around line 492-494: Replace the fire-and-forget setTimeout(...) calls that
invoke vscode.commands.executeCommand with an awaited delay helper and proper
error handling: add a delay function (e.g., delay = (ms: number) => new
Promise(r => setTimeout(r, ms))) and then use await delay(500); followed by
await vscode.commands.executeCommand('vscode.openWith', fileUri,
'rocketride.PageEditor') wrapped in a try/catch to surface errors; update both
occurrences that currently use setTimeout (the call around
vscode.commands.executeCommand and the similar block at the other location) and
ensure the containing function is async so callers can await the full operation.
In `@packages/shared-ui/src/modules/flow/components/FlowCanvas.tsx`:
- Around line 135-147: The effect uses React.useRef and React.useEffect
inconsistently with the rest of the file; import and use the named hook instead:
add useRef to the existing imports (since useEffect is already imported) and
replace React.useRef(...) with useRef(...) and React.useEffect(...) with
useEffect(...). Update the block that declares hasAutoLayouted and the effect
that references nodes, isLayouting, and autoLayout accordingly to keep naming
and usage consistent with the other hooks in this file.
In `@packages/shared-ui/src/modules/flow/util/graph.ts`:
- Around line 148-154: The current fallback uses the zero-check (ui.position.x
=== 0 && ui.position.y === 0) which can incorrectly overwrite a legitimate (0,0)
position; change the condition to detect whether the original UI position was
explicitly provided instead of testing for zeros. Replace the condition with a
check like "if (!(raw as Record<string, unknown>).ui?.position && (raw as
Record<string, unknown>).position) { ... }" so the fallback to raw.position only
runs when raw.ui.position is absent; keep the inner logic that reads
raw.position into ui.position (ui.position and raw.position are the unique
symbols to modify).
---
Duplicate comments:
In `@apps/vscode/src/providers/SidebarTemplatesProvider.ts`:
- Around line 44-64: The hard-coded provider arrays STORE_PROVIDERS,
LLM_PROVIDERS and the PROVIDER_OPTIONS map duplicate a source of truth; replace
them by importing or deriving the provider lists from the shared
metadata/service catalog module (e.g., the central providers list in shared-ui
or services metadata) so updates are managed in one place—modify
SidebarTemplatesProvider to import the canonical provider data and build
PROVIDER_OPTIONS from that import instead of defining
STORE_PROVIDERS/LLM_PROVIDERS inline.
- Around line 473-487: The template creation currently always writes to
workspaceFolder.uri; update the logic in SidebarTemplatesProvider that computes
fileName/fileUri (symbols: fileName, fileUri, workspaceFolder, slug) to honor
the rocketride.defaultPipelinePath setting: read the configured path via
vscode.workspace.getConfiguration('rocketride').get('defaultPipelinePath',
'pipelines'), resolve it against workspaceFolder.uri using vscode.Uri.joinPath
to produce a targetDirUri, ensure the directory exists (create if needed), and
then use targetDirUri when creating the unique fileUri loop instead of
workspaceFolder.uri so new .pipe files land in the configured pipelines folder.
- Around line 507-544: The scaffoldStarterPipeline function currently writes
getting-started.pipe into the workspace root and should respect the configured
defaultPipelinePath; update how starterFile is built by using the same pipeline
directory resolution as the template create command (read the
defaultPipelinePath setting or computed pipelineDir for the workspace) instead
of joining directly to workspaceFolder.uri, ensure the target directory exists
(create it if needed) and then write/open the file; key symbols to update:
scaffoldStarterPipeline, starterFile, and the logic that constructs the file Uri
so it uses the configured pipeline directory rather than the workspace root.
- Around line 91-354: The hard-coded TEMPLATES object duplicates the canonical
templates in shared-ui and should be replaced by a single source of truth;
remove the TEMPLATES constant in SidebarTemplatesProvider.ts and instead import
the JSON (or a shared TS module) from the shared-ui templates (e.g. import
templates from 'packages/shared-ui/src/modules/flow/templates/templates.json' or
from a new shared module), ensure the imported type aligns with TemplateInfo (or
export the type from the shared module), and update any code that references
TEMPLATES to use the imported templates—if your bundler disallows raw JSON
imports, create/export a shared TypeScript module (e.g. templates.ts) in
shared-ui and import that here or add a build step to generate this file from
templates.json.
In `@packages/shared-ui/src/modules/flow/templates/templates.json`:
- Around line 277-350: The multi-agent template currently sends input from
chat_1 to both agent_rocketride_1 and agent_rocketride_2 but only wires
agent_rocketride_1 to response_answers_1, leaving agent_rocketride_2 outputs
unused; either explicitly document agent_rocketride_2's role (e.g., add a "name"
or "description" field like "assistant/worker: supports agent_rocketride_1 via
shared memory" on the agent_rocketride_2 component and mention memory_internal_1
as shared memory), or wire agent_rocketride_2 outputs to an appropriate response
handler (e.g., add an input mapping from agent_rocketride_2 to
response_answers_1 or add a new response component) so users can see its
outputs.
🪄 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: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 41b59330-2dab-4574-b5d3-9ee82a4a70ce
📒 Files selected for processing (6)
apps/vscode/package.jsonapps/vscode/src/providers/SidebarTemplatesProvider.tspackages/shared-ui/src/modules/flow/components/FlowCanvas.tsxpackages/shared-ui/src/modules/flow/templates/templates.jsonpackages/shared-ui/src/modules/flow/util/graph.tspackages/shared-ui/src/themes/rocketride-vscode.css
There was a problem hiding this comment.
♻️ Duplicate comments (5)
apps/vscode/src/providers/SidebarTemplatesProvider.ts (4)
507-509: 🧹 Nitpick | 🔵 TrivialFire-and-forget
setTimeoutloses errors fromexecuteCommand.If
vscode.openWithfails (e.g., custom editor not registered, file locked), the error is silently swallowed. Using an awaited delay helper surfaces these errors:♻️ Suggested approach
+const delay = (ms: number) => new Promise((resolve) => setTimeout(resolve, ms)); + // ...inside the command handler after writeFile: -setTimeout(() => { - vscode.commands.executeCommand('vscode.openWith', fileUri, 'rocketride.PageEditor'); -}, 500); +await delay(500); +await vscode.commands.executeCommand('vscode.openWith', fileUri, 'rocketride.PageEditor');🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/vscode/src/providers/SidebarTemplatesProvider.ts` around lines 507 - 509, The current fire-and-forget setTimeout calling vscode.commands.executeCommand('vscode.openWith', fileUri, 'rocketride.PageEditor') can swallow exceptions; replace the setTimeout with an awaited delay helper (e.g., await delay(ms)) and then call await vscode.commands.executeCommand(...) inside a try/catch so any errors are surfaced/handled (log or rethrow). Update the logic around the call site in SidebarTemplatesProvider (the setTimeout block) to use the delay helper and explicit await/try-catch for executeCommand instead of a non-awaited setTimeout.
44-64: 🛠️ Refactor suggestion | 🟠 MajorDuplicate source of truth for provider options and templates.
This file hard-codes
STORE_PROVIDERS,LLM_PROVIDERS, and the entireTEMPLATEScatalog that already exists inshared-ui/templates.json. Changes to templates or providers will now require updates in two places, risking drift between the sidebar picker and the empty-canvas flow UI.Consider importing from a shared module or dynamically loading the templates JSON.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/vscode/src/providers/SidebarTemplatesProvider.ts` around lines 44 - 64, Replace the hard-coded provider lists (STORE_PROVIDERS, LLM_PROVIDERS) and any in-file TEMPLATES usage by importing the canonical data from the shared templates JSON/module (the same source used by shared-ui/templates.json), then derive PROVIDER_OPTIONS from that import instead of declaring arrays inline; update references to STORE_PROVIDERS, LLM_PROVIDERS and PROVIDER_OPTIONS to use the imported structure (or a computed mapping) so the sidebar picker and empty-canvas flow share a single source of truth.
563-565: 🧹 Nitpick | 🔵 TrivialSame fire-and-forget
setTimeoutpattern as noted above.Consider using the same awaited delay helper for consistent error handling.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/vscode/src/providers/SidebarTemplatesProvider.ts` around lines 563 - 565, Replace the fire-and-forget setTimeout call that invokes vscode.commands.executeCommand('vscode.openWith', starterFile, 'rocketride.PageEditor') with the project's awaited delay helper (the same helper used elsewhere) so the delay is awaited and errors can be handled consistently; locate the setTimeout invocation in SidebarTemplatesProvider.ts and change it to await delay(<milliseconds>) followed by calling vscode.commands.executeCommand with proper try/catch around that call to surface errors related to opening the starterFile in 'rocketride.PageEditor'.
499-501: 🧹 Nitpick | 🔵 TrivialEmpty catch silently swallows all filesystem errors.
While this pattern works for "file exists" checks, it also catches permission errors, disk full, or other unexpected filesystem issues. Consider explicit error checking:
♻️ Suggested improvement
} catch (err) { - break; // doesn't exist, use this name + // FileNotFound expected; re-throw unexpected errors + if (err instanceof vscode.FileSystemError && err.code === 'FileNotFound') { + break; + } + throw err; }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/vscode/src/providers/SidebarTemplatesProvider.ts` around lines 499 - 501, The empty catch in SidebarTemplatesProvider (inside the filename existence loop) swallows all fs errors; update the catch to inspect the thrown error (e.g., catch (err)) and only treat ENOENT as the "doesn't exist" case (perform break), while rethrowing or propagating other errors (permission, disk, etc.) so they aren't silently ignored; ensure this change is applied where the code currently uses a lone catch in the existence-checking loop inside the SidebarTemplatesProvider class/method.packages/shared-ui/src/modules/flow/templates/templates.json (1)
287-360: 🧹 Nitpick | 🔵 TrivialClarify agent_rocketride_2's intended role in the multi-agent-crew template.
agent_rocketride_2receives questions fromchat_1but itsanswersoutput is not connected toresponse_answers_1— onlyagent_rocketride_1's answers are routed to the response. If this is intentional (e.g., agent_2 is a worker/researcher supporting agent_1), consider adding a comment in the template description documenting the crew architecture.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/shared-ui/src/modules/flow/templates/templates.json` around lines 287 - 360, The template currently only routes answers from agent_rocketride_1 to response_answers_1 while agent_rocketride_2 receives questions but has no answers output — either connect agent_rocketride_2's answers to the response node or document its intended role; to fix, update the "components" array: add an input mapping { "lane": "answers", "from": "agent_rocketride_2" } to the response_answers_1 component if you want both agents' outputs shown, or edit the "multi-agent-crew" "description" string to explicitly state that agent_rocketride_2 is a background researcher/worker whose answers feed only to agent_rocketride_1 (and not to response_answers_1).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@apps/vscode/src/providers/SidebarTemplatesProvider.ts`:
- Around line 507-509: The current fire-and-forget setTimeout calling
vscode.commands.executeCommand('vscode.openWith', fileUri,
'rocketride.PageEditor') can swallow exceptions; replace the setTimeout with an
awaited delay helper (e.g., await delay(ms)) and then call await
vscode.commands.executeCommand(...) inside a try/catch so any errors are
surfaced/handled (log or rethrow). Update the logic around the call site in
SidebarTemplatesProvider (the setTimeout block) to use the delay helper and
explicit await/try-catch for executeCommand instead of a non-awaited setTimeout.
- Around line 44-64: Replace the hard-coded provider lists (STORE_PROVIDERS,
LLM_PROVIDERS) and any in-file TEMPLATES usage by importing the canonical data
from the shared templates JSON/module (the same source used by
shared-ui/templates.json), then derive PROVIDER_OPTIONS from that import instead
of declaring arrays inline; update references to STORE_PROVIDERS, LLM_PROVIDERS
and PROVIDER_OPTIONS to use the imported structure (or a computed mapping) so
the sidebar picker and empty-canvas flow share a single source of truth.
- Around line 563-565: Replace the fire-and-forget setTimeout call that invokes
vscode.commands.executeCommand('vscode.openWith', starterFile,
'rocketride.PageEditor') with the project's awaited delay helper (the same
helper used elsewhere) so the delay is awaited and errors can be handled
consistently; locate the setTimeout invocation in SidebarTemplatesProvider.ts
and change it to await delay(<milliseconds>) followed by calling
vscode.commands.executeCommand with proper try/catch around that call to surface
errors related to opening the starterFile in 'rocketride.PageEditor'.
- Around line 499-501: The empty catch in SidebarTemplatesProvider (inside the
filename existence loop) swallows all fs errors; update the catch to inspect the
thrown error (e.g., catch (err)) and only treat ENOENT as the "doesn't exist"
case (perform break), while rethrowing or propagating other errors (permission,
disk, etc.) so they aren't silently ignored; ensure this change is applied where
the code currently uses a lone catch in the existence-checking loop inside the
SidebarTemplatesProvider class/method.
In `@packages/shared-ui/src/modules/flow/templates/templates.json`:
- Around line 287-360: The template currently only routes answers from
agent_rocketride_1 to response_answers_1 while agent_rocketride_2 receives
questions but has no answers output — either connect agent_rocketride_2's
answers to the response node or document its intended role; to fix, update the
"components" array: add an input mapping { "lane": "answers", "from":
"agent_rocketride_2" } to the response_answers_1 component if you want both
agents' outputs shown, or edit the "multi-agent-crew" "description" string to
explicitly state that agent_rocketride_2 is a background researcher/worker whose
answers feed only to agent_rocketride_1 (and not to response_answers_1).
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: c3a561a3-bf2e-4633-bb05-cc5abb56b9be
📒 Files selected for processing (2)
apps/vscode/src/providers/SidebarTemplatesProvider.tspackages/shared-ui/src/modules/flow/templates/templates.json
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/shared-ui/src/modules/flow/components/FlowCanvas.tsx`:
- Around line 135-147: The effect currently calls autoLayout whenever
nodes.length > 0, which rewrites persisted layouts; change it to only
auto-layout when nodes are truly unpositioned. In the useEffect that references
hasAutoLayouted, nodes, isLayouting, and autoLayout, add a predicate that
inspects the nodes array (e.g., check that every node has no meaningful
position: node.position == null or position.x/y are 0) and only proceed to set
hasAutoLayouted.current and schedule autoLayout() when that predicate is true;
keep the existing timer/cleanup and guards (isLayouting, hasAutoLayouted) and
leave onToolchainUpdated behavior untouched in useAutoLayout.
- Around line 136-145: The auto-layout flag is set too early in the useEffect,
so StrictMode may clear the timeout before layout runs; modify the effect that
uses hasAutoLayouted, nodes, isLayouting and autoLayout so that
hasAutoLayouted.current is assigned true inside the setTimeout callback (after
calling autoLayout) instead of before scheduling the timer, and ensure the
effect still clears the timer on cleanup.
🪄 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: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 1261aef5-384e-4c97-9a3d-e118921d4db4
📒 Files selected for processing (2)
packages/shared-ui/src/modules/flow/components/FlowCanvas.tsxpackages/shared-ui/src/modules/flow/util/graph.ts
| // Auto-apply tidy layout on first load (when nodes appear from a file) | ||
| const hasAutoLayouted = useRef(false); | ||
| useEffect(() => { | ||
| if (nodes.length > 0 && !hasAutoLayouted.current && !isLayouting) { | ||
| hasAutoLayouted.current = true; | ||
| // Delay to let nodes measure first | ||
| const timer = setTimeout(() => { | ||
| autoLayout(); | ||
| }, 500); | ||
| return () => clearTimeout(timer); | ||
| } | ||
| }, [nodes.length, isLayouting, autoLayout]); | ||
|
|
There was a problem hiding this comment.
Auto-layout currently rewrites persisted node layouts on first open.
At Line 138, any non-empty graph triggers autoLayout() once. Since useAutoLayout repositions all nodes and calls onToolchainUpdated(), opening an already-arranged pipeline can immediately mutate layout unexpectedly.
♻️ Proposed fix (limit auto-layout to truly unpositioned graphs)
// Auto-apply tidy layout on first load (when nodes appear from a file)
const hasAutoLayouted = useRef(false);
useEffect(() => {
- if (nodes.length > 0 && !hasAutoLayouted.current && !isLayouting) {
+ const hasOnlyDefaultPositions =
+ nodes.length > 0 && nodes.every((node) => node.position.x === 0 && node.position.y === 0);
+
+ if (hasOnlyDefaultPositions && !hasAutoLayouted.current && !isLayouting) {
hasAutoLayouted.current = true;
// Delay to let nodes measure first
const timer = setTimeout(() => {
autoLayout();
}, 500);
return () => clearTimeout(timer);
}
- }, [nodes.length, isLayouting, autoLayout]);
+ }, [nodes, isLayouting, autoLayout]);📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| // Auto-apply tidy layout on first load (when nodes appear from a file) | |
| const hasAutoLayouted = useRef(false); | |
| useEffect(() => { | |
| if (nodes.length > 0 && !hasAutoLayouted.current && !isLayouting) { | |
| hasAutoLayouted.current = true; | |
| // Delay to let nodes measure first | |
| const timer = setTimeout(() => { | |
| autoLayout(); | |
| }, 500); | |
| return () => clearTimeout(timer); | |
| } | |
| }, [nodes.length, isLayouting, autoLayout]); | |
| // Auto-apply tidy layout on first load (when nodes appear from a file) | |
| const hasAutoLayouted = useRef(false); | |
| useEffect(() => { | |
| const hasOnlyDefaultPositions = | |
| nodes.length > 0 && nodes.every((node) => node.position.x === 0 && node.position.y === 0); | |
| if (hasOnlyDefaultPositions && !hasAutoLayouted.current && !isLayouting) { | |
| hasAutoLayouted.current = true; | |
| // Delay to let nodes measure first | |
| const timer = setTimeout(() => { | |
| autoLayout(); | |
| }, 500); | |
| return () => clearTimeout(timer); | |
| } | |
| }, [nodes, isLayouting, autoLayout]); |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/shared-ui/src/modules/flow/components/FlowCanvas.tsx` around lines
135 - 147, The effect currently calls autoLayout whenever nodes.length > 0,
which rewrites persisted layouts; change it to only auto-layout when nodes are
truly unpositioned. In the useEffect that references hasAutoLayouted, nodes,
isLayouting, and autoLayout, add a predicate that inspects the nodes array
(e.g., check that every node has no meaningful position: node.position == null
or position.x/y are 0) and only proceed to set hasAutoLayouted.current and
schedule autoLayout() when that predicate is true; keep the existing
timer/cleanup and guards (isLayouting, hasAutoLayouted) and leave
onToolchainUpdated behavior untouched in useAutoLayout.
| const hasAutoLayouted = useRef(false); | ||
| useEffect(() => { | ||
| if (nodes.length > 0 && !hasAutoLayouted.current && !isLayouting) { | ||
| hasAutoLayouted.current = true; | ||
| // Delay to let nodes measure first | ||
| const timer = setTimeout(() => { | ||
| autoLayout(); | ||
| }, 500); | ||
| return () => clearTimeout(timer); | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify whether the app uses React.StrictMode around the shared UI mount path.
# Expected: If StrictMode is present, this effect pattern is vulnerable in dev.
rg -n -C3 '<React\.StrictMode>|StrictMode' --type ts --type tsx --type js --type jsxRepository: rocketride-org/rocketride-server
Length of output: 103
🏁 Script executed:
#!/bin/bash
# Corrected search for React.StrictMode usage - omit invalid file type flags
rg -n 'React\.StrictMode|<StrictMode' --max-count 20Repository: rocketride-org/rocketride-server
Length of output: 377
🏁 Script executed:
#!/bin/bash
# Read the FlowCanvas.tsx file to see the full useEffect context
wc -l packages/shared-ui/src/modules/flow/components/FlowCanvas.tsxRepository: rocketride-org/rocketride-server
Length of output: 141
🏁 Script executed:
#!/bin/bash
# Read relevant lines from FlowCanvas.tsx to understand the context
sed -n '130,160p' packages/shared-ui/src/modules/flow/components/FlowCanvas.tsxRepository: rocketride-org/rocketride-server
Length of output: 1444
🏁 Script executed:
#!/bin/bash
# Check if FlowCanvas is imported in the StrictMode-wrapped apps
rg -l 'FlowCanvas' apps/dropper-ui apps/chat-ui 2>/dev/null || echo "Not found in those paths"Repository: rocketride-org/rocketride-server
Length of output: 100
🏁 Script executed:
#!/bin/bash
# Alternative: check if shared-ui is imported/used by the apps
rg 'shared-ui|FlowCanvas' apps/dropper-ui/src/index.tsx apps/chat-ui/src/index.tsxRepository: rocketride-org/rocketride-server
Length of output: 58
StrictMode can cancel the only scheduled auto-layout in development.
hasAutoLayouted.current is set to true before the timeout runs. In StrictMode's mount/cleanup/remount cycle, the first timer is cleared and the second pass won't reschedule because the flag is already set, preventing auto-layout from executing in dev.
Move the flag assignment inside the setTimeout callback to ensure it only gets set when the layout actually runs:
♻️ Proposed fix
const hasAutoLayouted = useRef(false);
useEffect(() => {
if (nodes.length > 0 && !hasAutoLayouted.current && !isLayouting) {
- hasAutoLayouted.current = true;
// Delay to let nodes measure first
const timer = setTimeout(() => {
+ hasAutoLayouted.current = true;
autoLayout();
}, 500);
return () => clearTimeout(timer);
}
}, [nodes.length, isLayouting, autoLayout]);🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/shared-ui/src/modules/flow/components/FlowCanvas.tsx` around lines
136 - 145, The auto-layout flag is set too early in the useEffect, so StrictMode
may clear the timeout before layout runs; modify the effect that uses
hasAutoLayouted, nodes, isLayouting and autoLayout so that
hasAutoLayouted.current is assigned true inside the setTimeout callback (after
calling autoLayout) instead of before scheduling the timer, and ensure the
effect still clears the timer on cleanup.
Senior Review: feat(vscode) — Template gallery sidebarWhat works well
Blockers (must fix before merge)
Should fix
Nice-to-have
Good feature — resolve the merge conflicts and verify the template wiring, and this should be close to ready. |
🚀 Merge RequestNice UX addition with 5 starter templates. Before merge:
Conflict resolution is the first step. @kwit75 |
Summary
Two features for new user onboarding:
1. Auto-open starter pipeline on first install
When the extension launches for the first time, it automatically creates
getting-started.pipewith a RAG Chat pipeline (Webhook → Parse → Chunk → Embed → Chroma → OpenAI → Response) and opens it in the editor. Users immediately see a working pipeline to learn from.2. Templates sidebar in Explorer
New "Templates" tree view in the Explorer sidebar listing all 8 starter templates:
Clicking a template shows a QuickPick for required providers (LLM, vector store), creates a new
.pipefile, and opens it in a new tab.Files changed
apps/vscode/package.json— new view, command, menu entriesapps/vscode/src/extension.ts— register provider, auto-open starterapps/vscode/src/providers/SidebarTemplatesProvider.ts— new file (template catalog + sidebar + scaffold logic)packages/shared-ui/src/modules/flow/templates/templates.json— 5 new templatesTest plan
getting-started.pipecreated and opened automaticallySummary by CodeRabbit
New Features
Improvements
Style