What causes "api: remote error [%d]: %s" in microsoft/typescript-go?

Read the message text - it is the error string from the peer's handler for the method you invoked

api: remote error [%d]: %s

Error message

api: remote error [%d]: %s

What it means

Returned (not panicked) by SyncConn.Call when the peer answered a server-to-client request with an error response. Under the msgpack protocol every remote failure is normalized to JSON-RPC code -32603 (internal error) with the peer's message text, so the printed message tells you what the client-side handler failed to do.

Source

Thrown at internal/api/conn_sync.go:194

	id := jsonrpc.NewIDString(method)

	if err := c.protocol.WriteRequest(id, method, params); err != nil {
		return nil, err
	}

	if ctx.Err() != nil {
		return nil, ctx.Err()
	}

	// Read the response inline.
	msg, err := c.protocol.ReadMessage()
	if err != nil {
		return nil, err
	}

	if msg.IsResponse() && msg.ID != nil && msg.ID.String() == method {
		if msg.Error != nil {
			return nil, fmt.Errorf("api: remote error [%d]: %s", msg.Error.Code, msg.Error.Message)
		}
		return msg.Result, nil
	}

	// Unexpected message while waiting for response
	return nil, fmt.Errorf("api: unexpected message while waiting for %q response", method)
}

// Notify sends a notification to the client (no response expected).
func (c *SyncConn) Notify(ctx context.Context, method string, params any) error {
	c.mu.Lock()
	defer c.mu.Unlock()
	return c.protocol.WriteNotification(method, params)
}

View on GitHub (pinned to 1bcfa18d79)

Solutions

Read the message text - it is the error string from the peer's handler for the method you invoked
Reproduce the failing operation manually on the client (e.g. stat/read the exact path shown)
Fix the client handler (restore the file, fix permissions, implement the method) and retry the server call
If the file legitimately vanished, send a filesChanged/deleted notification so the server drops its cached state instead of calling for it

Example fix

// before (client): readFile handler errors because the file was deleted

// after (client): notify the deletion first so the server invalidates state
client.Notify("filesChanged", api.APIFileChangeSummary{
	Deleted: []api.DocumentIdentifier{{FileName: "/abs/deleted.ts"}},
})

Defensive patterns

Strategy: retry

Try / catch

res, err := conn.Call(ctx, "readFile", params)
if err != nil {
	if strings.HasPrefix(err.Error(), "api: remote error [") {
		// the failure is on the peer's side; its message text says why
		log.Printf("client handler failed: %v", err)
	}
	return res, err
}

Prevention

Implement every callback method the server may Call (filesystem access especially)
Keep files the server knows about present, or notify deletions via filesChanged
Return descriptive errors from client handlers so the relayed message is actionable

When it happens

Trigger: The server issues a Call (e.g. a filesystem callback such as readFile/readDirectory) and the client's handler returns an error: the requested file no longer exists client-side, permissions fail, or the method is unimplemented.

Common situations: File deleted or renamed between the change notification and the callback; client running a virtual filesystem that rejects the path; permission errors on the client host; partially implemented client handlers.

Related errors

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