Future <Link> navigation is broken if prefetching that route takes longer than 3.8 sec

[jayphelps]

What version of Next.js are you using?

11.1.2/Canary

What version of Node.js are you using?

Any

What browser are you using?

Any

What operating system are you using?

Any

How are you deploying your application?

Any

Describe the Bug

The internal utility withFuture() sets internal state in the routes Map containing a Promise. When loading or prefetching, the internal loadRoute() uses the resolvePromiseWithTimeout (), which will reject after the given 3.8 second timeout.

If a route is navigated to for the first time without being prefetched, and the 3.8 timeout is triggered due to slow server/connection, an exception is thrown and ultimately the page will do a full navigation. However, if an attempt to prefetch the route is made by Next and it takes longer than 3.8 seconds, that exception is caught and swallowed in production mode. Because withFuture() does not listen for any rejections from the promise returned from generator() (or, unrelated, if generator() synchronously threw) the state stored in routes (passed into withFuture as the second argument ,map) is not cleaned up and the "future" promise stored in there will never be resolved nor rejected.

When induced, the symptom from the user is that clicking a <Link> does nothing visually, and no error is logged.

Expected Behavior

Preloading <Link>s that take longer than the timeout do not prevent future navigation to that route.

To Reproduce

To reproduce, clone/build/start this repo, but do NOT npm install because I've patched next to induce 5 second latency to the /about JS chunk only to make it easily reproducible: https://github.com/jayphelps/next-issue-28797

Alternatively, the general instructions for making your own:

• <Link href="/something"> to another page (without setting prefetch={false}).
• Some how induce latency over 3.8 seconds for only the JS /_next/static/chunks/pages/file.js for that particular page; it's much harder to reproduce if you induce general latency on everything, but consistently reproducible if only that one file.
• Visit that page with that <Link>.
• See in Network tab that JS resource is being prefetched, but taking longer than 3.8 seconds.
• Wait until JS resource download completes.
• Now click on the <Link>.
• See that nothing happens.

To confirm root cause, add a breakpoint to the prefetch error swallowing line, reproduce (seeing debugger pause on that breakpoint), then inspect internal routes map to see the hung promise stuck in 'pending' state forever.

If things are unclear, I'm happy to jump on Zoom, etc.

As always, apologies if I'm some how wrong and waste anyone's time 😅 I tried to be thorough. I would PR, but it’s unclear if the right approach is a more extreme refactor or just simply tweaking withFuture to listen for errors and cleanup—that might have consequences I’m unaware of because it’s used in several places.

[jayphelps]

This fixes it for us, and what we're now running in production: jayphelps@8daaa0a

-      generator().then((value) => (resolver(value), value))
+      generator()
+        .then((value) => (resolver(value), value))
+        .catch((e) => {
+          map.delete(key)
+          throw e
+        })

Though it's probably a good idea to catch any synchronous errors when calling generator() too (which we're not doing)

[jayphelps]

Edited original post to include a repo to reproduce the issue easily; I patched next-server.js in the node_modules (included) so that it always has 5 seconds of latency for the /about route chunk. https://github.com/jayphelps/next-issue-28797

[balazsorban44]

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.