Fix: helloworld-sample #1159

[ShubhamRoy123]

This PR fixes the issue where the helloworld-sample fails to compile automatically when pressing F5 on Windows.

The preLaunchTask was not correctly triggering the TypeScript compilation (npm: watch), resulting in a missing out directory and a "command not found" error when trying to run the extension. I have updated the task configuration to ensure it executes reliably across different Windows shell environments.

Related Issues
Closes #1159

Checklist
[x] I have tested these changes locally on Windows.

[x] The out directory is now correctly generated upon pressing F5.

[x] The "Hello World" command works immediately in the Extension Development Host.

[ShubhamRoy123]

@microsoft-github-policy-service agree

[ShubhamRoy123]

"LGTM" (Looks Good To Me) and please clicking an approve button.

[ShubhamRoy123]

Hi @mjbvz , I’ve addressed the issue where helloworld-sample failed to compile on Windows due to the preLaunchTask not correctly triggering TypeScript compilation.
I have updated the task configuration to ensure it executes reliably across different Windows shell environments and confirmed that the out directory is now correctly generated.
I also attatch .patch file from a protips advice.
Could you please review and approve these changes when you have a moment? Thanks!

[gabrielsalayacarrillo393-boop]

Muy bien
Creación

[ShubhamRoy123]

Muy bien Creación

Thank you for the review! I have cleaned up the branch and synced it with the latest main. Ready for a final check.

[eljoeepf-ui]

Si pos chikiti wow El sáb, 7 de feb de 2026, 11:12 p.m., Shubham Roy ***@***.***> escribió:

…

*ShubhamRoy123* left a comment (microsoft/vscode-extension-samples#1265) <#1265 (comment)> Muy bien Creación Thank you for the review! I have cleaned up the branch and synced it with the latest main. Ready for a final check. — Reply to this email directly, view it on GitHub <#1265 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B56DUKCMU6TUN6ZUN4T4EY34K3AU5AVCNFSM6AAAAACS5ZBKOCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQNRWGE4DIMJWGA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ShubhamRoy123]

@mjbvz good day sir , sir please i request to you to check my pr request . your small contribution is very helpful for me. and my future🙏

[mjbvz]

Thanks for taking a look. If watch isn't working, let's fix the root cause of that instead of trying to work around it

For what it's worth, the current setup seems to work fine for me on a Mac

[ShubhamRoy123]

Thanks for taking a look. If watch isn't working, let's fix the root cause of that instead of trying to work around it

For what it's worth, the current setup seems to work fine for me on a Mac

Thanks for the feedback, sir @mjbvz! I understand what i need to do next.

[ShubhamRoy123]

Thanks for taking a look. If watch isn't working, let's fix the root cause of that instead of trying to work around it

For what it's worth, the current setup seems to work fine for me on a Mac

@mjbvz Good day sir . I have identified the root cause as a race condition
i updated a tasks.json file and also sorry for late because i was test this extension on linux also with the help of docker.

Also I changed back from "npm: compile" to "npm:watch"
can you also review my changes. 🙏🙏

[lukas-2803]

I don't understand what you want? What you talking about?

…

On Wed, 11 Feb 2026, 23:25 Shubham Roy, ***@***.***> wrote: *ShubhamRoy123* left a comment (microsoft/vscode-extension-samples#1265) <#1265 (comment)> Thanks for taking a look. If watch isn't working, let's fix the root cause of that instead of trying to work around it For what it's worth, the current setup seems to work fine for me on a Mac @mjbvz <https://github.com/mjbvz> Good day sir . I have identified the root cause as a race condition i updated a tasks.json file and also sorry for late because i was test this extension on linux also with the help of docker. Also I changed back from "npm: compile" to "npm:watch" can you also review my changes. 🙏🙏 — Reply to this email directly, view it on GitHub <#1265 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BT2TC3FG3GITJ7DSADPJGYL4LN6ZJAVCNFSM6AAAAACS5ZBKOCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQOBWGQ4TAOBZHE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ShubhamRoy123]

@lukas-2803 good day sir
actually what is happening here
according to issue #1159
i saw an error

so i understand that the Compiler (tsc -w) and the Extension Host (the debugger) both start at the same time.
then i changed npm : watch to npm : compile but the problem is "In compile mode, every time you change a single line of code in your extension.ts, you have to stop the debugger and manually run the build again. " and
According to @mjbvz sir he suggest me instead of changing watch fix root cause and then i was working on this and i understand it's actually a race condition problem
the Compiler and the Debugger—start at the same time and "race" to access the same files. Because they aren't synchronized, the outcome depends entirely on which one finishing first.
On a machine with high I/O latency (like Windows 11), the Debugger often "wins" the race.
but if cpu is busy (high latency), there is a significant 'lag' between starting the task and the files appearing in the out directory. Without synchronization, the Debugger reaches for the entry point while it is still missing or being written, resulting in the 'Command not found' error.(which you see on screenshot)
you can think like you run this extension in old cpu laptop which is high latency where this error is guaranteed to show up. example :-"pentium cpu"

My Solution: I implemented a Background Problem Matcher in tasks.json that acts as a 'Safety Gate.'
*beginsPattern: Configured to detect the initial compilation message in the terminal. Technically, this signals to VS Code's task system that the background process is in an active/non-ready state, effectively blocking the dependent Debugger from attaching.

*endsPattern: Specifically targets the Found 0 errors. Watching for file changes. success string. Matching this pattern transitions the task state to "idle/ready," which acts as the release signal for the Extension Development Host.

Why this Fixes the Root Cause:-
1)Serialization of Parallel Processes: By using these patterns, I have converted an unpredictable parallel start into a serialized sequence. The Debugger is now programmatically prevented from attempting to load the extension entry point until the disk write operation is confirmed complete by the compiler.

2)Latency Independence: This ensures that even under high CPU load or I/O latency (which frequently occurs on Windows 11), the Extension Host will never encounter a missing out/extension.js file.

3)Preserved Incremental Workflow: Unlike switching to a standard compile task, this keeps the Background Watcher active, allowing for fast, incremental updates without losing the synchronization safety.

[lukas-2803]

I removed my slave form this projects can you see who are responsible to do echo

…

On Thu, 12 Feb 2026, 20:35 Shubham Roy, ***@***.***> wrote: *ShubhamRoy123* left a comment (microsoft/vscode-extension-samples#1265) <#1265 (comment)> @lukas-2803 <https://github.com/lukas-2803> good day sir actually what is happening here according to issue #1159 <#1159> i saw an error WhatsApp.Image.2026-02-12.at.9.17.52.PM.jpeg (view on web) <https://github.com/user-attachments/assets/9cfac837-224d-44fd-839b-00fa7dba68c0> so i understand that the Compiler (tsc -w) and the Extension Host (the debugger) both start at the same time. then i changed npm : watch to npm : compile but the problem is "In compile mode, every time you change a single line of code in your extension.ts, you have to stop the debugger and manually run the build again. " and According to @mjbvz <https://github.com/mjbvz> sir he suggest me instead of changing watch fix root cause and then i was working on this and i understand it's actually a race condition problem the Compiler and the Debugger—start at the same time and "race" to access the same files. Because they aren't synchronized, the outcome depends entirely on which one finishing first. On a machine with high I/O latency (like Windows 11), the Debugger often "wins" the race. but if cpu is busy (high latency), there is a significant 'lag' between starting the task and the files appearing in the out directory. Without synchronization, the Debugger reaches for the entry point while it is still missing or being written, resulting in the 'Command not found' error.(which you see on screenshot) *My Solution*: I implemented a Background Problem Matcher in tasks.json that acts as a 'Safety Gate.' *beginsPattern: Configured to detect the initial compilation message in the terminal. Technically, this signals to VS Code's task system that the background process is in an active/non-ready state, effectively blocking the dependent Debugger from attaching. *endsPattern: Specifically targets the Found 0 errors. Watching for file changes. success string. Matching this pattern transitions the task state to "idle/ready," which acts as the release signal for the Extension Development Host. Why this Fixes the Root Cause:- 1)Serialization of Parallel Processes: By using these patterns, I have converted an unpredictable parallel start into a serialized sequence. The Debugger is now programmatically prevented from attempting to load the extension entry point until the disk write operation is confirmed complete by the compiler. 2)Latency Independence: This ensures that even under high CPU load or I/O latency (which frequently occurs on Windows 11), the Extension Host will never encounter a missing out/extension.js file. 3)Preserved Incremental Workflow: Unlike switching to a standard compile task, this keeps the Background Watcher active, allowing for fast, incremental updates without losing the synchronization safety. — Reply to this email directly, view it on GitHub <#1265 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BT2TC3BYZWWJ62HYYTVL6T34LSTUJAVCNFSM6AAAAACS5ZBKOCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQOJRHE2TSNJVGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ShubhamRoy123]

@mjbvz good day sir , can you please review tasks.json file and approve my pr?🙏
Following your earlier suggestion, I have identified and fixed the root cause of the race condition

[ShubhamRoy123]

@meganrogge , good day Mam.

I have finalized the fix for the race condition in the helloworld-sample on Windows. Following @mjbvz's suggestion, I identified the root cause: the debugger was attempting to activate before the background watch task could finish writing the out directory.

My solution implements a deterministic synchronization handshake using a problemMatcher in tasks.json. This ensures the extension is only activated once the build success signal is received, making it 100% reliable even on high-latency systems.

I have verified this locally on Windows and docker ubuntu. Could you please do a final review? 🙏

[ShubhamRoy123]

Good day @mjbvz sir ,and @meganrogge mam I hubble request to you please if you take some miner time and give some updates of my pr

[ShubhamRoy123]

@mjbvz good day sir , sir please i request you again to check my pr request . your small contribution is very helpful for me. and my future🙏