[365] potential listener LEAK detected

[jrieken]

• have an eager comments controller extension (see below)
• open a notebook
• create a new cell
• leak warnings are printed

event.js:467 [365] potential listener LEAK detected, having 3431 listeners already. MOST frequent listener (3257):
event.js:468 Error
    at Stacktrace.create (event.js:478:35)
    at MainThreadCommentThread._event [as onDidChangeLabel] (event.js:576:44)
    at CommentThreadWidget._bindCommentThreadListeners (commentThreadWidget.js:150:69)
    at CommentThreadWidget.updateCommentThread (commentThreadWidget.js:98:18)
    at cellComments.js:79:55
    at process.processTicksAndRejections (node:internal/process/task_queues:96:5)

const cctrl = vscode.comments.createCommentController('foo', "HELLO")

	vscode.window.onDidChangeActiveTextEditor(e => {
		if (!e) {
			return;
		}
		const thread = cctrl.createCommentThread(e.document.uri, new vscode.Range(0, 0, 1, 1), [{
			author: { name: 'FOOO' },
			body: `Hello ${e.document.uri.path}`,
			mode: vscode.CommentMode.Editing
		}])

	})

[jrieken]

This seems to be rooted at updateCommentThread

It looks like a new _commentThreadDisposables is created without always disposing the old one. The if (this._commentThread !== commentThread) { looks highly suspicious.

[jrieken]

Suggesting to tackle this for October because after a short while VS Code was crawling due to excessive listening

[rebornix]

@jrieken thanks for good reproduce. The comment thread equality check is wrong, it's an oversight during refactoring iirc. I pushed a fix for this memory leak. Though with it fixed, I found there are issues with "Editing" state of comment thread for cells (focus issue), will look into this next week.

[jrieken]

Thanks @rebornix