Guard terminal resize/dispose race against xterm.js dimension getters

[bryanchen-d]

What

Guards three terminal resize/dispose race paths that throw Cannot read properties of undefined (reading 'dimensions') from xterm.js' RenderService.get dimensions() after the renderer is disposed.

Why

PR #313817 bumped @xterm/* to beta.213 and resolved the OverviewRulerRenderer dispose race (bucket 8612c55d, ✅ zero hits on post-fix insider builds). However three sibling buckets keep firing on the latest insiders (1.120.0-insider 79d6cea3 / 0aed0a9b):

Bucket	Caller	First seen on post-fix insider
aaa283a2	_resizeYCallback from configChange → setVisible → _resize	161 hits / 98 users
4826565b	debounced _debounceResizeX timer	909 hits / 497 users
1e83a096	_resizeBothCallback from _onProcessExit → dispose → setVisible(false) → _resize	291 hits / 98 users

All three reach RenderService.get dimensions() inside xterm.js, which dereferences this._renderer.value (undefined post-dispose) and throws synchronously. The optional chaining on rawXterm.dimensions?.css.canvas.width doesn't help because the getter itself throws before the ?. short-circuits.

The upstream 08ae141 patch added isDisposed guards at the OverviewRuler call sites — not inside the getter — so the symmetrical fix here is to guard the call sites VS Code owns.

Changes

terminalInstance.ts

• Bail out of the three resize closures passed to TerminalResizeDebouncer when this.isDisposed.
• _updatePtyDimensions: early-return when disposed; defensively try/catch around rawXterm.dimensions so a future renderer-dispose race fails silently with undefined dimensions instead of bubbling as an unhandled error.

terminalResizeDebouncer.ts

• resize / flush: bail out when this._store.isDisposed.
• runWhenWindowIdle callbacks: re-check disposed state before invoking the resize callback (the idle callback can fire after MutableDisposable.clear for a different timing reason).
• _debounceResizeX: re-check disposed state. The @debounce(100) decorator schedules a setTimeout that is not tied to the disposable store, so it can fire after the terminal/xterm is gone — this is the direct cause of bucket 4826565b.

How to test

1. Open a terminal, type or generate >200 lines of output.
2. Trigger the dispose-during-resize patterns:
   • Quickly close (Ctrl+Shift+W) a terminal while resizing the window.
   • Run a config change (e.g. toggle terminal.integrated.fontFamily) immediately after killing a terminal.
   • Kill a long-running shell from within the terminal (exit) while the panel is mid-resize.
3. Verify no unhandled dimensions TypeErrors in DevTools console.
4. Telemetry: monitor buckets aaa283a2, 4826565b, 1e83a096 over the next two insider builds — expect zero new occurrences.

Risk

• All guards are early-returns / try-catch around accessors — no behavior change in the live (non-disposed) path.
• Defensive try/catch in _updatePtyDimensions accepts a single missed dimension update if the renderer is mid-dispose; this is preferable to throwing and losing the entire reconnect/restore flow.
• No test changes; the races are timing-dependent and hard to reproduce deterministically. Telemetry will be the verification signal.

Refs #303546, #313817

[anthonykim1]

This just looks like we want to swallow known error instead of actually addressing root cause.

Seems like actual throw is from xterm not vscode.

@bryanchen-d What is the repro step for this dimension error? Is it causing breakage in terminal behavior?

[bryanchen-d]

It is hard to find the repro step. Essentially the error comes from calling term.dimensions after term.dispose(), so user shouldn't see visible breakage since the terminal has been disposed.

I think the try-catch here is no-harm here, but I'd agree we can remove it since we have already check isDisposed above.

[anthonykim1]

It will be harm if the root cause is somewhere else and this would prevent us from root-causing the issue.

[bryanchen-d]

That's fair, I made a follow up PR to revert that part, can you review?

[anthonykim1]

yes, already approved.