Socket.close() by the caller of a service-binding connect() is not delivered to the callee

[guybedford]

When the caller of a service-binding socket (env.X.connect(), and likewise a Durable Object stub) calls socket.close(), the callee's connect() handler is not told: a pending reader.read() on the callee's socket neither ends nor rejects. It stays pending after the caller's close() resolves, and still after the caller's request has finished.

Socket.close() cancels the readable and aborts the writable on the caller's side, so the callee should observe at least EOF (the caller has nothing more to write), if not an error. Neither crosses the in-process connection.

Repro

// worker.js
export default {
  async connect(socket) {
    const reader = socket.readable.getReader();
    const started = Date.now();
    try {
      const result = await reader.read();
      console.log('callee read settled:', JSON.stringify(result), `after ${Date.now() - started}ms`);
    } catch (e) {
      console.log('callee read rejected:', e.message, `after ${Date.now() - started}ms`);
    }
  },
};

export const closeFromCaller = {
  async test(ctrl, env) {
    const socket = env.SELF.connect('x:1');
    await socket.opened;
    await socket.close();
    console.log('caller close() resolved');
    await scheduler.wait(3000);
  },
};

using Workerd = import "/workerd/workerd.capnp";
const unitTests :Workerd.Config = (
  services = [( name = "main", worker = (
    modules = [(name = "worker", esModule = embed "worker.js")],
    compatibilityDate = "2025-06-01",
    bindings = [(name = "SELF", service = "main")],
  ))],
);

workerd test worker.wd-test prints caller close() resolved and then nothing from the callee for the remaining 3 seconds, nor after the test's request ends. Observed on main at 925464b.

By contrast, a clean half-close (writer.close()) is delivered as EOF, and an abort of the caller's writable through a pipeTo that fails is delivered as an error. Only Socket.close() is lost.

Impact

• The callee's handler, and with it its IoContext, stays pinned for as long as its read() is pending. For a callee reached from a long-lived caller (a connect() handler forwarding a TCP connection to a Durable Object, for instance) that is the lifetime of the caller's request, and the handler's own completion promise never settles.
• Any protocol whose only end-of-connection signal is the client closing the socket (as opposed to half-closing or erroring) leaves the server side waiting indefinitely. A Node.js socket.destroy() maps to this.
• Callers that tear down via an aborted pipe rather than close() are not affected, which is why it is easy to miss.

Found while testing net.Server over connect() (#7306).