Multi-zone not working on version 13.4.19. 13.4.3 works fine

[Zonalds]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
      Platform: darwin
      Arch: x64
      Version: Darwin Kernel Version 21.6.0: Mon Dec 19 20:44:01 PST 2022; root:xnu-8020.240.18~2/RELEASE_X86_64
    Binaries:
      Node: 16.14.0
      npm: 8.3.1
      Yarn: 1.22.19
      pnpm: 7.32.2
    Relevant Packages:
      next: 13.4.19
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0
      typescript: N/A
    Next.js Config:
      output: N/A


warn  - Latest canary version not detected, detected: "13.4.19", newest: "13.4.20-canary.3".
        Please try the latest canary version (`npm install next@canary`) to confirm the issue still exists before creating a new issue.
        Read more - https://nextjs.org/docs/messages/opening-an-issue
✨  Done in 5.96s.

Which area(s) of Next.js are affected? (leave empty if unsure)

No response

Link to the code that reproduces this issue or a replay of the bug

yarn dev

To Reproduce

on next.config.js add

const { APP_URL } = process.env

/** @type {import('next').NextConfig} */
const nextConfig = {
  async rewrites() {
    return [
      {
        source: '/:path*',
        destination: `/:path*`,
      },
      {
        source: '/app',
        destination: `${APP_URL}/app`,
      },
      {
        source: '/app/:path*',
        destination: `${APP_URL}/app/:path*`,
      },
    ]
  },
}

module.exports = nextConfig

on .env.local add
APP_URL=http://localhost:3001

http://localhost:3001 references another nextjs app on port 3001

Describe the Bug

When using Multi-zone to video a second app. The app refreshes indefinitely. The terminal prints https://nextjs.org/docs/messages/fast-refresh-reload

Expected Behavior

Downgrading to version 13.4.3 works fine. The app doesn't refresh indefinitely when using multi-zone

Which browser are you using? (if relevant)

Version 1.56.20 Chromium: 115.0.5790.171 (Official Build) (x86_64)

How are you deploying your application? (if relevant)

not deployed yet

[bryanbarrios]

This behavior has been occurring since version 13.4.13. Version 13.4.12 works normally.

[agustints]

I am also experiencing the same issue after upgrading to 13.4.13 and later versions.
The source main app (host app) works well, when navigating to apps that are under the rewrite rules, the app refreshes indefinitely and displays ⚠ Fast Refresh had to perform a full reload. Read more: https://nextjs.org/docs/messages/fast-refresh-reload.

[bjornsnoen]

Adding what I know here as I've been investigating this bug since yesterday. In our case we are running our main app on port 8080 and our subzone on 8081.

• Introduced in 13.4.13-canary-0, likely caused by Revert "Revert "Separate routing code from render servers (#52492)"" #53029, a frankly enormous refactor introduced in a patch release and mysteriously absent from the release notes, probably due to being a revert of a revert
• Still happens on 13.5.2
• Only happens in dev mode, prod mode works as it did prior to 13.4.13
• In the hmr websocket the final message before the reload is this

  {
   "event": "client-full-reload",
   "stackTrace": "SyntaxError: Unexpected token '<', \"<!DOCTYPE \"... is not valid JSON",
   "hadRuntimeError": false
  }

  which seems to indicate that the fast refresh isn't hitting the correct route and is getting an index page back.
• At the same time a request is sent to ${otherApp}/${otherAppBasePath}/_next/static/webpack/${hash}.webpack.hot-update.json. I can't catch the response body, but the headers indeed have Content-Type: text/html; charset=utf8 which is obviously wrong.
• The requested file does not exist, however if I am on the subzone app directly (in our case visiting http://subapp.localhost:8081/zonePath/) when I restart the dev server, another hot-update file is created with a different hash and successfully requested from the server.

I don't know what goes into the hash, but is it possible that the requested hash is wrong because it's using the port that the web browser is on and not the port that the underlying server is running on?

[exneval]

Just faced the issues in my side as well, 13.4.13-canary-0 break multi zones in dev server, even with 13.5.2

please take a look @ijjk @huozhi

[wjaykim]

It occurs in 13.5.4 as well, which prevents us upgrading from 13.4.4 to 13.5.x. Please take a look this issue.

[github-actions]

We cannot recreate the issue with the provided information. Please add a reproduction in order for us to be able to investigate.

Why was this issue marked with the please add a complete reproduction label?

To be able to investigate, we need access to a reproduction to identify what triggered the issue. We prefer a link to a public GitHub repository (template for App Router, template for Pages Router), but you can also use these templates: CodeSandbox: App Router or CodeSandbox: Pages Router.

To make sure the issue is resolved as quickly as possible, please make sure that the reproduction is as minimal as possible. This means that you should remove unnecessary code, files, and dependencies that do not contribute to the issue. Ensure your reproduction does not depend on secrets, 3rd party registries, private dependencies, or any other data that cannot be made public. Avoid a reproduction including a whole monorepo (unless relevant to the issue). The easier it is to reproduce the issue, the quicker we can help.

Please test your reproduction against the latest version of Next.js (next@canary) to make sure your issue has not already been fixed.

If you cannot create a clean reproduction, another way you can help the maintainers' job is to pinpoint the canary version of next that introduced the issue. Check out our releases, and try to find the first canary release that introduced the issue. This will help us narrow down the scope of the issue, and possibly point to the PR/code change that introduced it. You can install a specific version of next by running npm install next@<version>.

I added a link, why was it still marked?

Ensure the link is pointing to a codebase that is accessible (e.g. not a private repository). "example.com", "n/a", "will add later", etc. are not acceptable links -- we need to see a public codebase. See the above section for accepted links.

What happens if I don't provide a sufficient minimal reproduction?

Issues with the please add a complete reproduction label that receives no meaningful activity (e.g. new comments with a reproduction link) are automatically closed and locked after 30 days.

If your issue has not been resolved in that time and it has been closed/locked, please open a new issue with the required reproduction.

I did not open this issue, but it is relevant to me, what can I do to help?

Anyone experiencing the same issue is welcome to provide a minimal reproduction following the above steps. Furthermore, you can upvote the issue using the 👍 reaction on the topmost comment (please do not comment "I have the same issue" without reproduction steps). Then, we can sort issues by votes to prioritize.

I think my reproduction is good enough, why aren't you looking into it quicker?

We look into every Next.js issue and constantly monitor open issues for new comments.

However, sometimes we might miss one or two due to the popularity/high traffic of the repository. We apologize, and kindly ask you to refrain from tagging core maintainers, as that will usually not result in increased priority.

Upvoting issues to show your interest will help us prioritize and address them as quickly as possible. That said, every issue is important to us, and if an issue gets closed by accident, we encourage you to open a new one linking to the old issue and we will look into it.

Useful Resources

• How to Contribute to Open Source (Next.js)
• How to create a Minimal, Complete, and Verifiable example
• Reporting a Next.js bug
• Next.js Triaging issues

[liorheber]

I created this repository with the issue
https://github.com/liorheber/multizone-issue

[exneval]

It's so easy to reproduce:

Zone 1: https://codesandbox.io/p/sandbox/multi-zones-1-m79cw8

Zone 2: https://codesandbox.io/p/sandbox/multi-zones-2-xfk4d9

[francofantini]

Hi @samcx, have you been able to review the reproduction repos yet? Thank you.

[milo-]

Any updates on this? It's blocking us from upgrading 😢

[bryanbarrios]

In version 14 with App Router this issue doesn't occur, but Fast Refresh doesn't work anymore. When editing any file the change is not visible under the same URL of the Host app; it's necessary to navigate to the URL of the zone to see the new changes or reload the page for each change.
If I enable Turbopack, the same behavior happens as with Page Router.

[9vfQbg7z4ajrGQxR]

Please @ijjk @huozhi its blocking us for upgrading since 13.4.4 🙏 and quite restrictive for the use of turborepo