TypeError: range must be set at new Vd

[guardrex]

Type: Bug

Issue Description

Intermittently throws the following exception. Please help me route this if this isn't the correct repo for the report.

Steps to Reproduce

Unknown ... occurs intermittently.

Expected Behavior

No error.

Actual Behavior

2025-04-06 07:41:55.065 [info] [Error - 7:41:55 AM] Processing diagnostic queue failed.
2025-04-06 07:41:55.065 [info] TypeError: range must be set
	at new Vd (file:///c:/Users/XXXXXXXXXX/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/api/node/extensionHostProcess.js:107:19980)
	at new eJ (c:\Users\XXXXXXXXXX\.vscode\extensions\ms-dotnettools.csharp-2.69.25-win32-x64\dist\extension.js:80:57439)
	at l (c:\Users\XXXXXXXXXX\.vscode\extensions\ms-dotnettools.csharp-2.69.25-win32-x64\dist\extension.js:80:78725)
	at s (c:\Users\XXXXXXXXXX\.vscode\extensions\ms-dotnettools.csharp-2.69.25-win32-x64\dist\extension.js:80:51112)
	at Object.Slt [as map] (c:\Users\XXXXXXXXXX\.vscode\extensions\ms-dotnettools.csharp-2.69.25-win32-x64\dist\extension.js:80:51198)
	at Object.c [as asDiagnostics] (c:\Users\XXXXXXXXXX\.vscode\extensions\ms-dotnettools.csharp-2.69.25-win32-x64\dist\extension.js:80:78595)
	at L$.workDiagnosticQueue (c:\Users\XXXXXXXXXX\.vscode\extensions\ms-dotnettools.csharp-2.69.25-win32-x64\dist\extension.js:86:10941)
	at Immediate.<anonymous> (c:\Users\XXXXXXXXXX\.vscode\extensions\ms-dotnettools.csharp-2.69.25-win32-x64\dist\extension.js:86:10613)
	at process.processImmediate (node:internal/timers:483:21)

Logs

Prefer not to disclose, as they contain sensitive information.

Environment information

Extension version: 2.69.25
VS Code version: Code 1.99.0 (4437686ffebaf200fa4a6e6e67f735f3edf24ada, 2025-04-02T21:35:19.530Z)
OS version: Windows_NT x64 10.0.22631

[dibarbet]

This may be an issue with a specific diagnostic in a specific file - seems to be missing a valid diagnostic range. It may be possible to trigger by editing a certain file

@guardrex couple of questions

1. Is Razor involved in this scenario at all?
2. If it's C#, collecting the LSP trace logs would be really useful (described here) to see if there are any diagnostic responses missing a range. You can either look through them yourself, or share them with me privately (my microsoft email is listed on my github email, reference this issue number in an email).

[guardrex]

I'm not sure the answer to the first question. I'm editing markdown files (.md) for the ASP.NET Core doc set when the exception appears. These files do have code blocks in them with the Razor code language, but I'm not working with Razor files (.razor).

I'll take a look at getting trace logs soon, hopefully today or tomorrow ... Wednesday at the latest.

[guardrex]

I think I've discovered the problem. There are two Razor files mentioned by the two exceptions in the trace log that have non-standard Razor syntax. The syntax is placeholder content for the article reader to understand that they would see their app assembly name in the files ...

...
@using {APPLICATION ASSEMBLY}
@using {APPLICATION ASSEMBLY}.Shared

I'll modify this approach to displaying this content in the article to see if I can clear the exceptions.

I'll close this because I think I've discovered the problem with your help. Thanks @dibarbet! 🎷

UPDATE: Confirmed! I simply moved the important lines from the two files into the article by inlining the Razor markup into the text. After deleting the Razor files from the repo and closing and re-opening VSC, the diagnostics exceptions are gone. 🎉

[dibarbet]

cc also @ryzngard - even if the razor files have non-standard syntax, the Razor server should likely not be reporting (what I assume are) invalid diagnostics and causing the client to error. Will leave to them to re-open or not.