Event iterator loops indefinitely when the same id is sent

[Zonigaru]

Environment

@orpc/server: 1.13.6
bun: 1.3.10

Reproduction

The bug is present in Websocket, I haven't tested the other adapters.

Simple reproduction with this code (part of this documentation page: https://orpc.dev/docs/adapters/websocket):

import { RPCHandler } from "@orpc/server/bun-ws";
import { onError, os } from "@orpc/server";

// = Router

const eventIterator = os.handler(async function* ({ signal }) {
  while (signal && !signal.aborted) {
    yield { message: "Hello World!" };
    console.log(`Message sent`);
    await Bun.sleep(5000);
  }
});

const router = {
  subscribe: eventIterator,
};

// ==

const handler = new RPCHandler(router, {
  interceptors: [
    onError((error) => {
      console.error(error);
    }),
  ],
});

Bun.serve({
  port: 3000,
  fetch(req, server) {
    if (server.upgrade(req)) {
      return;
    }

    return new Response("Upgrade failed", { status: 500 });
  },
  websocket: {
    message(ws, message) {
      handler.message(ws, message, {
        context: {},
      });
    },
    close(ws) {
      handler.close(ws);
    },
  },
});

Then I use an API client such as Bruno or Postman, repeatedly sending this message:

{
  "i": 1,
  "p": {
    "u": "/subscribe",
    "b": {
      "json": {}
    }
  }
}

If you close the websocket client connection, you will see on the server side that the “Message sent” logs are still being iterated. I noticed that only the last message sent is aborted correctly. Would the handler replace the previous signal assigned to the ID without aborting it?

I understand that this issue only occurs if oRPC is misused without using a RPCLink. However, in production, attackers could exploit this vulnerability to unnecessarily overload the server.

Describe the bug

When an event iterator is present in the router and I use the correct message format with the same id, the previous signals are never aborted. This issue causes an endless loop, since the previous iterators are never aborted.

Additional context

No response

Logs

[dosubot]

Hi @Zonigaru! I'm Dosu and I’m helping the orpc team.

You've found a legitimate bug. The issue is in ServerPeer.open() in packages/standard-server-peer/src/server.ts - when a message with a duplicate ID arrives, the method creates a new AbortController and overwrites the previous one in the clientControllers Map without aborting it:

open(id: string): AbortController {
  this.clientEventIteratorQueue.open(id)
  const controller = new AbortController()
  this.clientControllers.set(id, controller)  // ⚠️ Overwrites without aborting
  return controller
}

This orphans the original controller, so when close() iterates through the Map to abort controllers, it only aborts the most recent one - previous iterators continue running indefinitely.

The fix would be to abort any existing controller before replacing it:

open(id: string): AbortController {
  this.clientEventIteratorQueue.open(id)
  
  const existingController = this.clientControllers.get(id)
  if (existingController) {
    existingController.abort(new Error(`Message ID ${id} reused`))
  }
  
  const controller = new AbortController()
  this.clientControllers.set(id, controller)
  return controller
}

All WebSocket adapters (bun-ws, ws, websocket, crossws) inherit this issue since they all delegate to ServerPeer. There are currently no tests for duplicate message ID scenarios, so this appears to be an unhandled edge case.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[dinwwwh]

Let try this fix #1474

[Zonigaru]

Thank you! I confirm that the fix has resolved the issue.