next.js: Next 13 /_next/webpack-hmr pending indefinitely with custom server

still exists next@13.4.10

Facing same issue in next 14.0.2. Webpack-hmr just never finishes.

I’m experiencing the same issue with the Payload Custom Server Example which uses the Next.js App Router for its demonstration. It worked flawlessly with the Pages Router, but since upgrading to App Router, HMR no longer works. The app compiles in real-time but the browser requires a refresh to see the changes.

The issue was introduced with https://github.com/vercel/next.js/pull/49805/files

It adds an extra proxy layer but does not proxy WebSockets. next-dev-server magically adds a WebSocket handler to the request’s server such that if you use custom server (express or http.createServer) and pass req to the next.js handler (returned by .getRequestHandler()) you will have a WebSocket handler on your custom server.

However, since v13.4.3-canary.3 next.js forces creation of render-server instead, which is similar to a custom server in that it calls next({ ... }) and forwards requests to it, while the next({ ... }) you called simply proxies requests to render-server (render-server-standalone.ts). But render-server is it’s own HttpServer. In this case next-dev-server adds WebSocket handler onto the HttpServer of render-server. And there is nothing that would forward WebSocket from your custom server to the render-server to even have a chance to be forwarded to next-dev-server.

render-server-standalone.ts should have had it’s own version of what DevServer.setupWebSocketHandler does.

I take that back. The upgrade handler gets added automatically on the first request as before. However, I am adding my own websocket to a custom server (needs to be on the same port). I only handle upgrade requests that match a certain path, much like the HMR upgrade handler that only handles requests for _next/webpack-hmr.

But, commit 1398de9977b89c9c4717d26e213b52bc63ccbe7e introduced in 13.4.13 made it so the socket gets closed when not handled by HMR (before, it worked fine to have the HMR upgrade handler added to the server alongside my own). This is bad because there is now currently no clean way I can see to add your own socket to the routing server. I think the plan is to support upgrade requests in app/pages routes, but like I said the socket is now being closed instead of being allowed to continue.

I’m working around it for now with the following…

// ...
const handle = app.getRequestHandler()
const upgradeHandler = app.getUpgradeHandler()

app.prepare().then(() => {
  const server = createServer((req, res) => {
    const parsedUrl = parse(req.url!, true)
    handle(req, res, parsedUrl)
  })

  server.on('upgrade', (req, socket, head) => {
    const parsedUrl = parse(req.url!, true)
    if (parsedUrl.pathname === '/our-custom-socket-path') {
      return handleUpgradeOurselves(req, socket, head)
    }
    // Let next.js handle the rest
    return upgradeHandler(req, socket, head)
  })
  
  // Keep the next.js upgrade handler
  // from being added to our custom server so
  // sockets stay open even when not HMR.
  const originalOn = server.on.bind(server)
  server.on = function (event, listener) {
    if (event !== 'upgrade') {
      return originalOn(event, listener)
    }
    return server
  }

  server.listen(port)
// ...

Sorry, that won’t work either. It fixed my own websocket, but HMR stopped working. I had assumed I could call the upgradeHandler in the 'upgrade' event listener, but that’s apparently not equivalent. ~If I want both, I’ll have to downgrade to 13.4.12.~ 13.4.19 seems to have a HMR fix for custom server + app router (which I think is OP’s issue), but I’m kind of stuck.

Fixing the user websocket regression would be a big bonus for me.

@ijjk I think all that would be needed to fix any user websockets would be to remove this line.

Side note: I think these are all related to HMR with a custom server + app router: #51162, #51028, #50881, #50400

@luca-vogels getRequestHandler() and getUpgradeHandler() don’t do what you think they do if you have appDir. They actually point to completely different servers, with the latter being a no-op server, so using getUpgradeHandler() is futile. The issue is much deeper.

Instead of

server.ts -> NextServer

is it

server.ts -> Proxy -[getRequestHandler]-> custom handler -> httpProxy -> router worker -> real NextServer
server.ts -> Proxy -[getUpgradeHandler]-> dummy NextServer

WebSocket was just completely overlooked in this extra proxy layer. Someone with a deeper understanding of how and why all of this was implemented this way should have a look and come up with a proper fix.

Here is roughly what is missing to support getUpgradeHandler():

--- a/node_modules/next/dist/server/lib/render-server-standalone.js
+++ b/node_modules/next/dist/server/lib/render-server-standalone.js
@@ -75,7 +75,7 @@ const createServerHandler = async ({ port , hostname , dir , dev =false , minima
         return proxyServer;
     };
     // proxy to router worker
-    return async (req, res)=>{
+    return async (req, res, socket, head)=>{
         const urlParts = (req.url || "").split("?");
         const urlNoQuery = urlParts[0];
         // this normalizes repeated slashes in the path e.g. hello//world ->
@@ -90,7 +90,11 @@ const createServerHandler = async ({ port , hostname , dir , dev =false , minima
             return;
         }
         const proxyServer = getProxyServer(req.url || "/");
-        proxyServer.web(req, res);
+        if (head) {
+            proxyServer.ws(req, socket, head)
+        } else {
+            proxyServer.web(req, res);
+        }
         proxyServer.on("error", (err)=>{
             res.statusCode = 500;
             res.end("Internal Server Error");
diff --git a/node_modules/next/dist/server/next.js b/node_modules/next/dist/server/next.js
index 2e3acc4..78fcff7 100644
--- a/node_modules/next/dist/server/next.js
+++ b/node_modules/next/dist/server/next.js
@@ -302,6 +302,20 @@ function createServer(options) {
                                 return server.render(req, res, pathname, query, parsedUrl);
                             };
                         }
+                    case "getUpgradeHandler":
+                        {
+                            return ()=> {
+                                let handler;
+                                return async (req, socket, head) => {
+                                    if (shouldUseStandaloneMode) {
+                                        const standaloneHandler = await handlerPromise;
+                                        return standaloneHandler(req, undefined, socket, head);
+                                    }
+                                    handler = handler || server.getUpgradeHandler();
+                                    return handler(req, socket, head);
+                                };
+                            }
+                        }
                     default:
                         {
                             const method = server[propKey];

If you find yourself in a situation where you can not downgrade (due to other fixes in 13.4.3+) and your local setup is barely usable (without HMR) then:

https://github.com/ds300/patch-package

Disclaimer: The maintenance of local patches is on you. If you can wait while on 13.4.2, better do so.

patches/next+13.4.6.patch (can be 13.4.3 to 13.4.6):

diff --git a/node_modules/next/dist/server/lib/render-server-standalone.js b/node_modules/next/dist/server/lib/render-server-standalone.js
index bc7de33..c960d94 100644
--- a/node_modules/next/dist/server/lib/render-server-standalone.js
+++ b/node_modules/next/dist/server/lib/render-server-standalone.js
@@ -11,6 +11,7 @@ Object.defineProperty(exports, "createServerHandler", {
 const _httpproxy = /*#__PURE__*/ _interop_require_default(require("next/dist/compiled/http-proxy"));
 const _jestworker = require("next/dist/compiled/jest-worker");
 const _utils = require("../../shared/lib/utils");
+const _log = require("../../build/output/log");
 function _interop_require_default(obj) {
     return obj && obj.__esModule ? obj : {
         default: obj
@@ -74,8 +75,28 @@ const createServerHandler = async ({ port , hostname , dir , dev =false , minima
         });
         return proxyServer;
     };
+
+    // Fix hot module replacement with a standalone server
+    let addedUpgradeListener = false
+    const setupWebSocketHandler = (req) => {
+        if (addedUpgradeListener) {
+            return;
+        }
+        let server = req?.socket?.server;
+        if (!server) {
+            _log.error(`Invalid IncomingMessage received, make sure http.createServer is being used to handle requests.`);
+        } else {
+            server.on("upgrade", async (req, socket, head) => {
+                const proxyServer = getProxyServer(req.url || '/')
+                proxyServer.ws(req, socket, head)
+            });
+            addedUpgradeListener = true;
+        }
+    }
+
     // proxy to router worker
     return async (req, res)=>{
+        setupWebSocketHandler(req);
         const urlParts = (req.url || "").split("?");
         const urlNoQuery = urlParts[0];
         // this normalizes repeated slashes in the path e.g. hello//world ->

13.4.19 does indeed seem to be working, but I think the custom server example needs to be updated to include getUpgradeHandler…

// ...
const handle = app.getRequestHandler()
const upgradeHandler = app.getUpgradeHandler()

app.prepare().then(() => {
  const server = createServer((req, res) => {
    const parsedUrl = parse(req.url!, true)
    handle(req, res, parsedUrl)
  })

  server.on('upgrade', upgradeHandler)

  server.listen(port)

// ...

Downgrade next to 13.3 works for me 🤷 (needed to add appDir: true in config)

I would also like to add I’m encountering this issue. I’m running next.js 13.5.4, with a REST server hosted on Flask. The Webpack-hmr request remains infinitely pending in my browser tools. Note, this does not have any impact on my hot-reload.

Issue got fixed in latest canary build next@13.4.14-canary.0

I can confirm this.

No hacks necessary now?