You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ext-http: SIGABRT 'there is no reactor running' (server/server.rs:913) — node:http server + ws WebSocketServer + fetch #8747
Env: perry 0.5.1512 built from main@6173ff9f6, macOS arm64. MB24 Phase-0 spike.
Repro:
import{createServer}from"node:http";import{WebSocketServer}from"ws";consthttpServer=createServer((_req,res)=>{res.writeHead(200);res.end("http-ok");});constwss=newWebSocketServer({server: httpServer});awaitnewPromise<void>((r)=>httpServer.listen(8137,r));console.log("listening");// reachedconstres=awaitfetch("http://127.0.0.1:8137/");// crash while serving this
Actual: hard abort (exit 134):
thread '<unnamed>' (49791956) panicked at crates/perry-ext-http/src/server/server.rs:913:38:
there is no reactor running, must be called from the context of a Tokio 1.x runtime
Expected: plain HTTP requests served alongside a ws upgrade handler on the same server (the standard single-port WS + REST layout).
Note: upstream main has 4 newer ext-http commits (#8615/#8608/#8632/#8641) but they target the client/Agent side; the panic site is in the server path. Full test: mobilitybroker24/monorepo spike/tests/07-ws.ts.
Closed by #8769, landed on main via #8778 (squash 1f5c3bb80).
That PR was landed through a batch wrapper PR rather than merged directly, so GitHub's close keyword never fired at merge time. Verified before closing: changelog.d/8769-http-ws-reactor-scheduling.md is present on main, and the accept loops now schedule through the reactor-owned async bridge.
Activity
proggeramlug commentedon Aug 24, 2026
Closed by #8769, landed on
mainvia #8778 (squash1f5c3bb80).That PR was landed through a batch wrapper PR rather than merged directly, so GitHub's close keyword never fired at merge time. Verified before closing:
changelog.d/8769-http-ws-reactor-scheduling.mdis present onmain, and the accept loops now schedule through the reactor-owned async bridge.