fix(vscode): fall back to active pipeline editor for commands

[techadnank9]

• Fixes a VS Code/Cursor extension bug where RocketRide pipeline commands could fail with No pipeline file selected or No pipeline selected when a valid .pipe file was already open in the active editor but no sidebar item was selected.
• Adds a fallback that resolves the active .pipe or .pipe.json editor when no PipelineFileItem is passed, and applies it to the open file, open status, and run pipeline command paths.
• Adds a focused regression test for the fallback helper so editor-driven invocation stays covered.

Type

fix

Testing

• Tests added or updated
• Tested locally
• ./builder test passes

Local verification performed:

pnpm exec tsc apps/vscode/src/test/sidebarCommandContext.test.ts apps/vscode/src/providers/sidebarCommandContext.ts --module Node16 --moduleResolution Node16 --target ES2022 --outDir build/sidebar-context-test && node --test build/sidebar-context-test/test/sidebarCommandContext.test.js


<!-- This is an auto-generated comment: release notes by coderabbit.ai -->
## Summary by CodeRabbit

* **Bug Fixes**
  * Sidebar commands now fail early with clearer "Invalid pipeline file or missing project_id" when a pipeline URI or context can't be resolved.
  * More reliable handling when opening or running pipeline files to prevent unexpected no-ops.

* **Improvements**
  * More consistent detection of pipeline files across editor and tabs with predictable fallbacks.
  * Unified validation across sidebar actions for steadier command behavior.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 28086022-f417-432d-8e2d-de135256df6b

📥 Commits

Reviewing files that changed from the base of the PR and between 9ebcc75 and f12d884.

📒 Files selected for processing (3)

• apps/vscode/src/providers/SidebarFilesProvider.ts
• apps/vscode/src/providers/sidebarCommandContext.ts
• apps/vscode/src/test/sidebarCommandContext.test.ts

---

📝 Walkthrough

Walkthrough

Centralizes pipeline URI and source-component resolution into a new helper module and updates three VS Code sidebar command handlers to use the shared resolvers; commands now fail earlier when URI or pipeline context cannot be determined.

Changes

Cohort / File(s)	Summary
Command Handler Refactor apps/vscode/src/providers/SidebarFilesProvider.ts	Replaced ad-hoc URI/context extraction with resolveCommandResourceUri, getActivePipelineEditorUri, and resolveKnownPipelineCommandContext. Updated openFile, openStatus, and runPipeline to resolve URIs via the shared helpers, add early exits when resolution fails, and centralize pipeline parsing/source-id resolution.
URI & Context Resolvers apps/vscode/src/providers/sidebarCommandContext.ts	New module exporting resolvePipelineCommandUri() (chooses explicit URI or falls back to active editor/tab if filename matches pipeline patterns) and resolvePipelineSourceComponentId() (resolves source component id with explicit/pipeline/source-components precedence).
Tests apps/vscode/src/test/sidebarCommandContext.test.ts	New unit tests covering precedence and fallback behaviors for resolvePipelineCommandUri() and resolvePipelineSourceComponentId() across explicit, active editor, active tab, and parsed sources scenarios.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• feat(vscode): Move Pipelines pane to Explorer and fix project_id #292: Modifies the same VS Code SidebarFilesProvider command handlers and pipeline command-resolution flow.

Suggested reviewers

• jmaionchi
• stepmikhaylov

Poem

🐰 I hopped through URIs, keen and spry,
Found pipelines hiding where editors lie.
Helpers gathered each fuzzy clue,
Now commands know just what to do.
Hop—tests checked—good things compile! 🥕

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 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: adding fallback logic to resolve the active pipeline editor for commands when no sidebar item is selected, which directly addresses the core bug fix.

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

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

[coderabbitai]

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 `@apps/vscode/src/providers/SidebarFilesProvider.ts`:
- Around line 223-225: The active-editor fallback assumes the parsed-file cache
is already populated and can return undefined projectId/source; fix
SidebarFilesProvider by parsing the resourceUri on demand when item?.parsedFile
is falsy: call the parsing helper used by loadPipelineFiles (or add a new
synchronous/awaitable parsePipelineFromUri helper) inside the code paths that
compute parsedFile/projectId/source (the locations using parsedFile?.projectId
and parsedFile?.pipeline, and the similar block at lines ~341-347) and await it
before calling the connection manager; alternatively, fail fast with a clear
error before execute if parsing cannot produce projectId/source. Ensure
getParsedPipeline (or the new helper) is awaited where invoked (see the note
about awaiting at line 159).
- Line 146: The code opens pipeline files with
vscode.commands.executeCommand(..., 'rocketride.PageEditor') but later checks
vscode.window.activeTextEditor?.document.uri (which is undefined for custom
editors), so replace that check with the Tabs API: get
vscode.window.tabGroups.activeTabGroup.activeTab and if tab?.input instanceof
vscode.TabInputCustom use (tab.input as vscode.TabInputCustom).uri as the active
URI; otherwise fall back to vscode.window.activeTextEditor?.document.uri; update
the logic around where activeTextEditor is referenced (the code relying on
activeTextEditor/document.uri) to use this Tabs API check so the custom
rocketride.PageEditor tab is detected correctly.

In `@apps/vscode/src/test/sidebarCommandContext.test.ts`:
- Around line 28-59: The test file only calls the pure helper
resolvePipelineCommandUri with synthetic { fsPath } objects, so it never
exercises the command path in SidebarFilesProvider where item === undefined and
parsedFiles may be empty; add a provider-level test that invokes the actual
command handler on SidebarFilesProvider (e.g., call the command method that uses
parsedFiles and item) with a mocked VS Code active editor/tab state and no
sidebar selection, asserting the command falls back to the active editor when
it's a .pipe or .pipe.json and returns undefined for non-pipeline files; mock or
stub the provider's parsedFiles and the VS Code API objects
(activeTextEditor/tab) to reproduce the real command-path behavior and verify
the regression is caught.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 26506c5b-22ca-4917-93c9-6e859ffe7c73

📥 Commits

Reviewing files that changed from the base of the PR and between f11c60c and 9ebcc75.

📒 Files selected for processing (3)

• apps/vscode/src/providers/SidebarFilesProvider.ts
• apps/vscode/src/providers/sidebarCommandContext.ts
• apps/vscode/src/test/sidebarCommandContext.test.ts

[jmaionchi]

hi @techadnank9 - please review and address/resolve all the coderabbitai comments/feedback.