Change:
<ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ declare const __analyzeSnapshotInTests: (currentTest: string, classes: readonly string[]) => Promise<({ done: Promise<number[]>; file: string })>; let currentTest: Mocha.Test | undefined; const snapshotsToAssert: ({ counts: Promise<number[]>; file: string; test: string; opts: ISnapshotAssertOptions })[] = []; setup(function () { currentTest = this.currentTest; }); suiteTeardown(async () => { await Promise.all(snapshotsToAssert.map(async snap => { const counts = await snap.counts; const asserts = Object.entries(snap.opts.classes); if (asserts.length !== counts.length) { throw new Error(`expected class counts to equal assertions length for ${snap.test}`); } for (const [i, [name, doAssert]] of asserts.entries()) { try { doAssert(counts[i]); } catch (e) { throw new Error(`Unexpected number of ${name} instances (${counts[i]}) after "${snap.test}":nn${e.message}nnSnapshot saved at: ${snap.file}`); } } })); snapshotsToAssert.length = 0; }); export interface ISnapshotAssertOptions { classes: Record<string, (count: number) => void>; } const snapshotMinTime = 20_000; /** * Takes a heap snapshot, and asserts the state of classes in memory. This * works in Node and the Electron sandbox, but is a no-op in the browser. * Snapshots are process asynchronously and will report failures at the end of * the suite. * * This method should be used sparingly (e.g. once at the end of a suite to * ensure nothing leaked before), as gathering a heap snapshot is fairly * slow, at least until V8 11.5.130 (https://v8.dev/blog/speeding-up-v8-heap-snapshots). * * Takes options containing a mapping of class names, and assertion functions * to run on the number of retained instances of that class. For example: * * ```ts * assertSnapshot({ *	classes: { *		ShouldNeverLeak: count => assert.strictEqual(count, 0), *		SomeSingleton: count => assert(count <= 1), *	} *}); * ``` */ export async function assertHeap(opts: ISnapshotAssertOptions) { if (!currentTest) { throw new Error('assertSnapshot can only be used when a test is running'); } // snapshotting can take a moment, ensure the test timeout is decently long // so it doesn't immediately fail. if (currentTest.timeout() < snapshotMinTime) { currentTest.timeout(snapshotMinTime); } if (typeof __analyzeSnapshotInTests === 'undefined') { return; // running in browser, no-op } const { done, file } = await __analyzeSnapshotInTests(currentTest.fullTitle(), Object.keys(opts.classes)); snapshotsToAssert.push({ counts: done, file, test: currentTest.fullTitle(), opts }); } </ins>

Discussion:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --Currently we are manually hunting down memory leaks through Dev Tools. For some areas/components (e.g., notebook), this even needs to be done repeatedly. It would be helpful if we can capture the memory snapshots in CI and write some queries against the snapshot to analyze if there is any potential leaks. A typical manual memory leak analysis for notebook Setup Open OSS Open notebook document A Open notebook document B Close both notebook documents Open Dev Tools, take a heap snapshot Search object, there should be none Search object, there should be none Search object, there should not be more than one (the editor group still holds a reference to the last editor) ! cc
The dev tools also show how an object is leaked, we could analyze the dependencies tree and figure out who is the "culprit"
would be a good API for CI use case on desktop to capture from any non-sandboxed process (Main, Utility - Ext Host, Shared Process, Pty Agent) embedding V8 without using external CDP calls. In the case of sandboxed render process, prefer
I find this topic super interesting as well! I have a prototype project that tries to find memory leaks by looking for leaking event listeners. In the screencast, the event listener count increases from 1175 to 1206 which indicates that there might be a memory leak when opening and closing a notebook editor. The project is in the early phases and in the future I'm hoping to display more detailed output for the event listeners as well as making the tests less flaky. (sorry if I'm interrupting the discussion. I'm hoping that perhaps this could be useful for you)