While SyncConn.Call handles a nested request from a client callback, it releases its lock, so another goroutine's call can start inside the client's pending nested request. Responses are matched by method name, so the nested answer and both callback answers then reach the wrong requests.

Impact: a resolver callback that delegates to another resolver, the pattern the API's own test shows, binds most imports to the wrong module once the loader uses more than one thread. Every type and diagnostic the tool reads from that program is then wrong, and no error says so. In the reproduction, 873 of 900 nested answers went to another request.

The connection now keeps a stack of the exchanges in flight. A new call waits while another call is innermost, and a request is answered only once it is innermost again, which is the order a synchronous client handles them in.

A call made from a notification handler while another call is waiting now blocks. No HandleNotification in the tree makes a call today.

TestSyncConnNestedRequestsAnswerInStackOrder drives two overlapping callbacks against a fake synchronous client under testing/synctest. It fails on each of 20 runs without the change. With a tsc built from this branch, the reproduction in the issue gives 900 right answers of 900. TestSyncConnRunReturnsResponseWritePanic keeps a panic inside WriteResponse returning an error from Run, as it does on main.

I met this while building deadset-ts, the TypeScript analyzer of deadset, on the TypeScript 7 API, as part of a small set of defects that work hit, which is why there are a few related reports from me.

An AI coding agent wrote this patch. I have read, built and tested it and will handle the review.

• There is an associated issue in the Backlog milestone (required)
• Code is up-to-date with the main branch
• You've successfully run npx hereby test
• You've successfully run npx hereby lint
• You've successfully run npx hereby check:format
• There are new or updated tests validating the change

Fixes #64631