microsoft/typescript-go · error · Error

this._msgPayload.toString("utf-8")

Error message

this._msgPayload.toString("utf-8")

What it means

This is the channel's server-error propagation: when the child answers a request with an MSG_ERROR frame whose name matches the request, the payload (the server's error message, e.g. 'unknown method', assertion failures, invalid arguments) is re-thrown on the client as a plain Error. It is the normal path by which every server-side failure surfaces in sync-client code — the message text itself comes from tsgo, not this file.

Source

Thrown at _packages/native-preview/src/api/syncChannel.ts:313

        for (;;) {
            this.readTuple();

            switch (this._msgType) {
                case MSG_RESPONSE: {
                    // Compare raw bytes instead of decoding to string.
                    if (!methodBuf.equals(this._msgName)) {
                        throw new Error(
                            `name mismatch for response: expected \`${method}\`, got \`${this._msgName.toString("utf-8")}\``,
                        );
                    }
                    if (this.collectTiming) {
                        this.lastBytesReceived = this._msgPayload.length;
                    }
                    return this._msgPayload;
                }
                case MSG_ERROR: {
                    if (methodBuf.equals(this._msgName)) {
                        throw new Error(this._msgPayload.toString("utf-8"));
                    }
                    throw new Error(
                        `name mismatch for response: expected \`${method}\`, got \`${this._msgName.toString("utf-8")}\``,
                    );
                }
                case MSG_CALL: {
                    this.handleCall(this._msgName.toString("utf-8"), this._msgPayload);
                    break;
                }
                default:
                    throw new Error(`Invalid message type from child: ${this._msgType}`);
            }
        }
    }

    // ── Callback handling ───────────────────────────────────────────

    /**

View on GitHub (pinned to 1bcfa18d79)

Solutions

1. Read the propagated message — it identifies the actual server-side failure and usually the fix
2. Ensure object ids passed (snapshot ids, project ids, object handles) come from the current session's responses
3. Wrap API calls in try/catch and surface the message; recreate the client if state-dependent ids are implicated

Example fix

// before
const r = client.apiRequest("someMethod", { snapshot: oldId });

// after
try {
  const r = client.apiRequest("someMethod", { snapshot: currentId });
} catch (e) {
  console.error("tsgo server error:", (e as Error).message);
}

try { data = client.apiRequest("method", args); } catch (e) {
  const msg = (e as Error).message;
  if (msg.includes("unknown") || msg.includes("invalid")) { /* fix arguments/ids per message */ }
  else if (msg.includes("name mismatch")) { /* desync: recreate client */ }
  else throw e;
}

When it happens

Trigger: Any server-side exception during an API request: passing invalid snapshot/project/object ids (e.g. after state was released), malformed request payloads, unimplemented methods, or internal tsgo assertion failures. The matching error 77/79 name checks do not fire here — this is the well-matched error case.

Common situations: Calling APIs with stale object ids from previous snapshots; requesting methods unavailable in the running binary version; hitting genuine tsgo bugs.

Related errors

• ${method} returned null symbol for ${source.constructor.name
• ${method} returned no type for ${source.constructor.name} ${
• ${method} returned null signature for ${source.constructor.n
• Symbol ${data.id} references unknown canonical project '${da
• SyncRpcChannel is closed

AI-assisted analysis of microsoft/typescript-go@1bcfa18d79 (2026-08-16). Data as JSON: /api/errors/0a90f10bd5225a48. Report an issue: GitHub.