Skip to content

feat(vscode) - Adding additional csharp lsp server functionality#8828

Open
lambrianmsft wants to merge 36 commits intoAzure:ccastrotrejo/csharpLSPServerfrom
lambrianmsft:ccastrotrejo/csharpLSPServer
Open

feat(vscode) - Adding additional csharp lsp server functionality#8828
lambrianmsft wants to merge 36 commits intoAzure:ccastrotrejo/csharpLSPServerfrom
lambrianmsft:ccastrotrejo/csharpLSPServer

Conversation

@lambrianmsft
Copy link
Contributor

Commit Type

  • feature - New functionality
  • fix - Bug fix
  • refactor - Code restructuring without behavior change
  • perf - Performance improvement
  • docs - Documentation update
  • test - Test-related changes
  • chore - Maintenance/tooling

Risk Level

  • Low - Minor changes, limited scope
  • Medium - Moderate changes, some user impact
  • High - Major changes, significant user/system impact

What & Why

Adding ability to open overview page for a workflow, adding a new workflow, reducing the connection pane load time, and updating the package.

Impact of Change

  • Users:
    Workflows runs can now be opened and new workflows can be added
  • Developers:
  • System:

Test Plan

  • Unit tests added/updated
  • E2E tests added/updated
  • Manual testing completed
  • Tested in:

Contributors

Screenshots/Videos

… call times for checking child process, added options to add new codeful workflows to the project, optimzed the get-child-process.ps1 script, and finally added the overview page for codeful workflows and ability to view runs
…d to be passed as a path and added additional telemetry to capture this whenever it happens
…ger name isn't defined, we pull the default from the lsp server sdk. Disabled the create unit test from run for codeful workflows
…perience, prevent callback url from getting continuously pinged, updated sdk version
@github-actions
Copy link

github-actions bot commented Feb 19, 2026

🤖 AI PR Validation Report

PR Review Results

Thank you for your submission! Here's detailed feedback on your PR title and body compliance:

PR Title

  • Current: feat(vscode) - Adding additional csharp lsp server functionality
  • Issue: The title is broadly accurate (feature) but is vague and doesn't clearly call out the main surface area or high-impact changes. This PR is large (36 commits, 80 files changed, +4145/-534) and touches LSP, project creation, debugging, packaging, run-time helpers, PowerShell scripts, and many tests — the title should reflect that to help reviewers quickly understand scope.
  • Recommendation: Make it specific and briefly list the main areas changed. Example: feat(vscode): Add C# LSP & codeful workflow support (C#/.NET8) — project scaffolding, debug, LSP metadata, and tooling

Commit Type

  • Properly selected (feature).
  • Note: Only one commit type box was selected in the PR body which is correct.

Risk Level

  • Current (PR body): Medium
  • Issue: The repository labels do not include a risk label (e.g. risk:low|medium|high). Every PR must have a risk label. More importantly: after reviewing the code diff, the impact is larger than "Medium".
    • This PR is large (80 files changed, many subsystems updated) and touches runtime logic, packaging, PowerShell scripts, authentication flows, deployment logic, LSP binary and SDK updates, debugging behavior, and many UI/workflow surface areas.
    • There are changes that affect process detection and runtime start/validation logic (PowerShell and process-check improvements), credentials and Azure connector caching, extension bundle version updates, new LSP assets, and code-generation for codeful workflows.
  • Recommendation: Update the PR risk selection to High in the PR body and add the corresponding repository label risk:high. I advise risk:high (you currently listed Medium).

(Note: advised risk is higher than the one assigned in the PR description — please update the PR risk field and add a risk:high label.)

⚠️ What & Why

  • Current: "Adding ability to open overview page for a workflow, adding a new workflow, reducing the connection pane load time, and updating the package."
  • Issue: This is short and missing important details. The PR touches many subsystems (LSP server + SDK upgrade, codeful workflow generation, project scaffolding, launch/tasks/settings JSON changes, PowerShell script and process detection, caching and telemetry, many tests). The body doesn't call out the LSP SDK addition, extension bundle bump, changes to connection insertion logic, codeful support (Program.cs modifications and workflow builders), or the new/modified assets and scripts.
  • Recommendation: Expand the What & Why to explicitly list major functional changes — include a short bulleted list such as:
    • Added C# (codeful) workflow support: project scaffolding, Program.cs workflow builders, .csproj and nuget handling
    • LSP server & SDK update: include new LSP zip and SDK nupkg, add LSP metadata request to fetch trigger names
    • Debugging: new getDebugConfiguration behavior for codeful projects, picking .NET host child process improvements
    • Runtime/process detection: updated PowerShell script and caching of validation results
    • Connection editor: fix race between add-connection and insert-connection, write/read ordering changes to use connections.json key
    • Performance & reliability: caching (bundle & azure connector details), parallelized work (connection reference updates), pre-warm operations
    • Tests: many unit tests added for codeful, LSP/completionFilter, connection view, startDesignTimeApi, and others

Include short rationale for each change and what user problem it solves.

Impact of Change

  • Issue: The PR body only filled Users (briefly) and left Developers and System blank. Given the scope, you must document specific impacts.
  • Recommendation: Fill out Impact of Change with explicit bullet points. For example:
    • Users: New ability to create and debug "codeful" C# workflows, open overview for codeful workflows, and faster connection pane experience.
    • Developers: New code paths for project creation and debug; new LSP request custom/getWorkflowMetadata (requires language server); changes to APIs for workspace creation; added/changed tests (paths below). Note the new shape changes: IWebviewProjectContext now uses typed ProjectType and optional targetFramework, changed constant names (agentCodeful -> codeful) and customExtensionContext keys.
    • System / Ops: Updated extension bundle version and shipped LSP artifacts (.zip and .nupkg), changed PowerShell scripts (get-child-processes), added caching for bundle & azure connector details, changes to packaging step (package.json build script runs npm install in dist). Call out any added runtime dependencies and assets.

Also include migration notes: e.g., updated config keys in local.settings (WORKFLOW_CODEFUL_ENABLED) and the extension context keys changed (isAgentCodeful -> isCodeful).

Test Plan

  • PR Body: Marked E2E tests and Manual testing only (Unit tests were unchecked).
  • Issue: The code diff includes many unit and integration tests added/updated (vitest test files and new test suites). The Test Plan in the PR body should reflect that and link to representative tests and CI expectations.
  • Recommendation: Update Test Plan checkboxes to:
    • Unit tests added/updated — list representative test files: e.g. apps/vs-code-designer/src/app/commands/createNewCodeProject/CodeProjectBase/test/CreateLogicAppWorkspace.test.ts, apps/vs-code-designer/src/app/commands/workflows/languageServer/test/connectionViewRace.test.ts, apps/vs-code-designer/src/app/languageServer/test/completionFilter.test.ts, apps/vs-code-designer/src/app/utils/test/codeful.test.ts, etc.
    • E2E tests added/updated (if applicable) — if there are E2E tests, list them; if not, uncheck.
    • Manual testing completed — provide steps executed manually (e.g., created codeful workspace, started design-time API, created codeful workflow, validated debug attach and run trigger) and environments used (Windows/macOS/Linux) and any limitations.

If any tests are flaky or require environment configuration (e.g., LSP binary or .nupkg artifacts), mention that and add CI guidance.

⚠️ Contributors

  • Current: (blank)
  • Issue: No contributors are listed. While not required, it's helpful to credit reviewers/PM/Designers. Please add contributors (names or GitHub handles) who helped with design, testing, or implementation.
  • Recommendation: Add a Contributors section listing people who reviewed, QA'd, or co-authored.

⚠️ Screenshots/Videos

  • Current: (blank)
  • Assessment: This PR introduces UI changes (webview panels, connection view loading state, command bar options, designer command bar unit-test support). Consider adding screenshots or short GIFs for major UI changes (connection view loading, overview page for codeful workflows, new designer command bar unit test button) to help reviewers.
  • Recommendation: Attach at least 2 screenshots (designer overview with codeful workflow, connection view loading) or short recordings for interactive behavior.

Summary Table

Section Status Recommendation
Title Make the title more descriptive of scope (LSP, codeful, debug, packaging)
Commit Type feature is correct
Risk Level Update to High and add risk:high label
What & Why Expand with a bulleted list of major changes and rationale
Impact of Change Document Users/Developers/System impacts and migration notes
Test Plan Mark Unit tests added/updated and list key tests; provide manual steps
Contributors ⚠️ Add contributors (optional but recommended)
Screenshots/Videos ⚠️ Add screenshots for key UI changes (recommended)

Summary / Action Items

  • Update the PR title to be more specific about what changed (LSP + codeful + debug + packaging). Example: feat(vscode): Add C# LSP & codeful workflow support (C#/.NET8) — scaffolding, debug, LSP metadata, and tooling.
  • Change PR Risk Level to High in the PR body and add the risk:high label to the PR.
  • Update the Test Plan checkboxes: mark Unit tests added/updated (this PR adds many unit tests). Provide a short list of representative test file paths and confirm CI runs them. If E2E tests were added, list them; otherwise adjust checkboxes accordingly.
  • Expand the "What & Why" and "Impact of Change" sections with explicit bullets covering: LSP asset additions, extension bundle bump, codeful workflow generation & Program.cs changes, debugging changes, connection insertion race fix, PowerShell script changes, caching and telemetry, packaging/build script change (package.json build:extension line), and potential user-facing behavior changes.
  • Add contributor credits.
  • If the PR introduces UI changes, include screenshots or short videos.

Please update the PR body (and labels) with the items above; once updated I will re-check the PR for compliance.

If you want, I can propose a full, updated PR body (with filled template) and an improved PR title for you to paste into the PR.

Note on risk: I recommend risk:high. This is higher than your PR body selection (Medium) because of the breadth and depth of changes (LSP binaries, extension bundle updates, runtime/process validation adjustments, packaging script changes, PowerShell changes, and many cross-cutting behavioral changes). Please update the risk field and add the appropriate label. Thank you!


Last updated: Wed, 11 Mar 2026 00:03:19 GMT

} else {
// For codeless projects, build custom code functions if they exist
const customFolderExists = await fse.pathExists(path.join(logicAppNode.fsPath, libDirectory, customDirectory));
if (customFolderExists) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't this be if !customFolderExists? Since we would build in the case where lib/custom/* doesn't already exist for codeless, i.e. not already built

// For codeless projects, build custom code functions if they exist
const customFolderExists = await fse.pathExists(path.join(logicAppNode.fsPath, libDirectory, customDirectory));
if (customFolderExists) {
await buildCustomCodeFunctionsProject(actionContext, logicAppNode);
Copy link
Contributor

Choose a reason for hiding this comment

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

buildCustomCodeFunctionsProject is supposed to check whether the .net project is specifically a custom code functions project before building, part of that is to check for Microsoft.Azure.Workflows.Webjobs.Sdk in the .csproj, which I don't think will exist for codeful projects. Should there be a separate function for handling building codeful?


// Find the location to insert the new workflow builder
// Look for the "Build all workflows" comment or insert before host.Run()
const buildCallRegex = /(\s*)(\/\/ Build all workflows\s*\n(?:\s*\/\/.*\n)*\s*)(.*?)(\s*host\.Run\(\);)/s;
Copy link
Contributor

Choose a reason for hiding this comment

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

Is it possible to avoid using a regex here to update Program.cs with a new workflow, and instead just overwrite Program.cs with one containing all workflows? We would need to track the workflows in a codeful project elsewhere, but we should probably avoid using regex as much as possible since it's bound to break in some cases

…ppsUX into ccastrotrejo/containerExtension"

This reverts commit 375a8ba, reversing
changes made to ac433d8.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants