#192753 and #172967 include lots of information about this bug

Initial findings:

• Main process is delayed waiting on the shutdownPromise to resolve.
• Delay comes from exiting long running extension host in waitForExit
• Profiling the extension host shows that the Node.js is delayed in its cleanup of exit callbacks at https://github.com/nodejs/node/blob/b45e196bec407c9db30ffe5490bb86be692a1579/src/env.cc#L1180-L1186
• ⚠️ Disabling telemetry resolves the slow shutdown of the extension host "telemetry.telemetryLevel": "off"

@bpasero @lramos15 this is a return of #172967 but we have reliable repro this time. @lramos15 do we run any telemetry network requests from inside the extension host, if so can you point me to the code.

Great findings 👏 , I am not sure if this is relevant here, but I do have noticed for quite some time now that quitting "Code OSS" (i.e. when I run out of sources and develop) takes a lot longer now to return back to the terminal. I was almost about to file an issue but maybe its the same? Would this repro even out of sources?

Yup it repos in out of sources as well as the product builds

@lramos15 this is a return of #172967 but we have reliable repro this time. @lramos15 do we run any telemetry network requests from inside the extension host, if so can you point me to the code.

Extensions can run telemetry from within the ext host (including built-in ones), but our core telemetry is all proxied over IPC

Extensions can run telemetry from within the ext host (including built-in ones)

Where do the network requests for these originate from, do they still get issued from the shared process ? Can you point to this code path as well.

Where do the network requests for these originate from, do they still get issued from the shared process ? Can you point to this code path as well.

I'm just talking about how each extension can send telemetry by instantiating its own reporter which uses the built-in http node module.

Regression started with @vscode/extension-telemetry version bump in ecb0c80, all versions >= 0.8.2 are affected. Bisect revealed the following commit microsoft/vscode-extension-telemetry@c31b67b as the trigger.

Further debugging narrowed it to the following callsite https://github.com/microsoft/vscode-extension-telemetry/blob/80cfe9538a0f1512de3fe8b4a1e1f1e34d9b2efa/src/common/1dsClientFactory.ts#L80-L85 which queues network requests when disposing the telemetry client causing the event loop to be busy.

Currently we have logic in extension host destruction code path to wait for 5s and allow extensions to cleanly dispose themselves before killing the extension host via process.exit, refs

One thing I found interesting is that, the old applicationinsights package has a nice utility to signal that the process is exiting in their flush API which then stores the data to disk synchronoushly if opted otherwise destorys itself immediately without any IO, refs https://github.com/microsoft/ApplicationInsights-node.js/blob/aaafbfd8ffbc454d4a5c30cda4492891410b9f66/Library/Channel.ts#L80-L88. I couldn't find a similar utility in the 1DS package. Maybe thats what we need to address this issue sanely from the package side. For the short term I suggest to revert the shutdown flushing to avoid impacting application shutdown behavior.

@lramos15 I leave to you to decide the best way forward for this issue.

on m2 pro - speed for close out in the dock is somewhat variable (not sure if this is an issue, it's still faster, but anywhere from 3-4 seconds).

on m2 pro - speed for close out in the dock is somewhat variable (not sure if this is an issue, it's still faster, but anywhere from 3-4 seconds).

Did you disable all extensions?

correction: works fine in insiders, very quick within 2 seconds of quitting.