fix: drop empty MessagePort frames instead of forwarding unparseable buffers (fixes #326171)

[vs-code-engineering]

Summary

TypeError: Cannot read properties of undefined (reading '0') is thrown from the IPC protocol reader in src/vs/base/parts/ipc/common/ipc.ts. Two coalesced buckets hit the same root cause from both directions of the channel:

• c161d9c4 — ChannelClient.onBuffer → ipc.ts:757 (const type = header[0])
• a0fde558 — ChannelServer.onRawMessage → ipc.ts:398 (const type = header[0])

In both cases header = deserialize(reader) returns undefined, then header[0] throws. deserialize returns undefined when it reads a message whose first byte cannot be matched to a DataType — most notably when the incoming VSBuffer is zero-length: reader.read(1) yields an empty buffer, readUInt8(0) yields undefined, the switch falls through, and deserialize returns undefined.

The zero-length buffer is manufactured by the MessagePort transport in src/vs/base/parts/ipc/common/ipc.mp.ts. When a message event arrives with no (or empty) data, the old code returned VSBuffer.alloc(0) and forwarded it through onMessage into the channel readers, which cannot parse an empty frame. An empty frame is never a valid protocol message (the smallest valid frame still carries a serialized header), so it must be dropped at the transport boundary rather than delivered.

Fixes #326171
Recommended reviewer: @deepak1556

Culprit Commit

ipc.mp.ts and ipc.ts were not modified inside the flagged regression window (1a31eba2...e8a3eada, 2026-07-10). The empty-frame → alloc(0) fallback is long-standing (introduced by 972172bc "fix: for message event data can be null"). The 22x spike in 1.129.0 was therefore triggered by an upstream component that began delivering empty MessagePort frames more frequently; that producer could not be pinned down from the available signal within budget. The transport-boundary handling of empty frames is the deterministic point where the invalid (empty) buffer enters the channel pipeline, and is fixed here.

Code Flow

flowchart TD
    A[MessagePort 'message' event with empty/null data] --> B[Protocol.onMessage in ipc.mp.ts]
    B -->|returns VSBuffer.alloc 0| C[ChannelClient.onBuffer / ChannelServer.onRawMessage]
    C --> D[deserialize reads no valid type byte]
    D -->|returns undefined| E[const type = header 0]
    E --> F[TypeError: Cannot read properties of undefined reading 0]

Loading

Affected Files

• src/vs/base/parts/ipc/common/ipc.mp.ts — MessagePort transport; produces the empty buffer (fixed here).
• src/vs/base/parts/ipc/common/ipc.ts — channel readers onBuffer (line 757) and onRawMessage (line 398); crash sites (not modified).

Repro Steps

1. Run VS Code desktop where a channel client/server communicates over a MessagePort (utility/shared process connections).
2. Cause the port to deliver a message event whose data is null or a zero-length Uint8Array (e.g. during connection teardown / process shutdown).
3. The transport forwards a zero-length VSBuffer; deserialize returns undefined; header[0] throws the unhandled TypeError.

How the Fix Works

Chosen approach — src/vs/base/parts/ipc/common/ipc.mp.ts: filter empty frames out at the transport boundary so they are never forwarded to the channel readers. The message map now returns VSBuffer | undefined (undefined when there is no data), and an Event.filter drops any value that is missing or has byteLength === 0. After this change, Protocol.onMessage can no longer emit a zero-length buffer, so ChannelClient.onBuffer (ipc.ts:755) and ChannelServer.onRawMessage (ipc.ts:396) can no longer receive a buffer that deserialize turns into an undefined header — the header[0] read is unreachable for empty input.

This fixes the data at the point it enters our pipeline (the producer of the invalid empty buffer) rather than guarding the crash site: no try/catch is added, no logService.error is removed, and the typed deserialize utility body is untouched. Dropping an empty frame loses no information because a zero-byte frame could never have encoded a valid message (a valid frame is always at least a header byte plus a body byte).

Alternatives considered:

• Guarding at the crash site in onBuffer/onRawMessage (e.g. if (!header) return) — rejected: that guards the consumer/crash site and hides where the bad buffer originates instead of stopping it at the producer.
• Changing deserialize to tolerate an empty reader — rejected: that patches a shared, typed serialization utility to absorb malformed input, masking the transport-level defect for every caller.

Recommended Owner

@deepak1556 — authored the MessagePort empty/null data handling in ipc.mp.ts (972172bc, "fix: for message event data can be null") and related MessagePort transport work, making them the closest owner for this transport-boundary change.

Generated by errors-fix · 1.9K AIC · ⌖ 34.1 AIC · ⊞ 70.8K · ◷

---

errors-fix-driver — cycle 1

Trigger: cron_check_failed · Head: 3c1f71f352f5cedc1f46d480430c4f52e91f52f2 (3c1f71f)

Item	Action
CI: Compile & Hygiene (real — tsc type error)	Fixed in 3c1f71f

The Compile & Hygiene job was the only check running full tsc type-checking (the platform matrix jobs transpile-only), so it alone surfaced the error. The type-guard overload of Event.filter over Event<VSBuffer | undefined> resolved to the boolean overload, widening the inferred Protocol.onMessage property to Event<VSBuffer | undefined>, which is not assignable to the base IMessagePassingProtocol.onMessage: Event<VSBuffer>. Reworked the transport so the mapped event stays Event<VSBuffer> (empty data maps to VSBuffer.alloc(0)) and empty frames are dropped with a plain boolean Event.filter(onMessage, data => data.byteLength > 0) — unambiguous overload, identical drop-empty-frames behavior.

Push: yes — 3c1f71f · Copilot rerequested: ok

Ready gate: CI pending after push → not evaluating ready this cycle.

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• electronjs.org

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "electronjs.org"

See Network Configuration for more information.

Generated by errors-fix-driver · 1.4K AIC · ⌖ 33.5 AIC · ⊞ 72.7K · ◷

[Copilot]

Copilot can't review bot-authored pull requests automatically. A user with Copilot access can request a review manually.

[Copilot]

Copilot can't review bot-authored pull requests automatically. A user with Copilot access can request a review manually.

[vs-code-engineering]

Commit pushed: bac2202

Generated by errors-fix-driver · 1.4K AIC · ⌖ 33.5 AIC · ⊞ 72.7K

[Copilot]

Copilot can't review bot-authored pull requests automatically. A user with Copilot access can request a review manually.