Enabling PPR causes HTTP 500 when scanned by bots

[mwskwong]

Link to the code that reproduces this issue

https://github.com/mwskwong/http-500-when-visit-by-bot

To Reproduce

1. Bootstrap a Next.js app with the CLI
2. Enable PPR in the config file

Deployed version: https://http-500-when-visit-by-bot.vercel.app/

Current vs. Expected behavior

Current The app will throw a 500 error when it is scanned by social media bots, typically when sharing the link of the website on social media. Reproduced on LinkedIn, Twitter, and Facebook (also with their share debuggers respectively).

It seems that it's a hydration error, but I'm not sure why does it show up on the server log.

Expected It should not throw an error when the site is scanned by bot.

Verify canary release

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

Provide environment information

Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Home
Binaries:
  Node: 20.9.0
  npm: N/A
  Yarn: N/A
  pnpm: 8.14.1
Relevant Packages:
  next: 14.0.5-canary.56
  eslint-config-next: 14.0.5-canary.56
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.3.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

App Router

Which stage(s) are affected? (Select all that apply)

Vercel (Deployed), Other (Deployed)

Additional context

No response

[mwskwong]

Update: Reddit, Discord, WhatsApp don't seem to be affected by this.

[libhide]

I'm seeing this too. WhatsApp seems to be a problem for me. Twitter, Reddit, iMessage work. LinkedIn, WhatsApp not working. I opened a discussion regarding this too here before I saw this issue.

Is there a fix that can be done for this?

[mwskwong]

As a side note: Leerob's site, which is also using PPR, suffers from the same issue.

[libhide]

@leerob 👀

[leerob]

I am not seeing an issue rendering social cards as mentioned for leerob.io.

Slack

LinkedIn

[mwskwong]

I am not seeing an issue rendering social cards as mentioned for leerob.io.

Slack LinkedIn

Interesting, on LinkedIn, sharing home page for real is fine, but Post Inspector complaints.

https://www.linkedin.com/post-inspector/inspect/https:%2F%2Fleerob.io

Yet, for blog pages, which uses PPR for real, the issue is reproducible.

Edit: Thinking of that, @leerob, the current behavior you experienced in LinkedIn may be due to LinkedIn caching the metadata. You may try to share the auto-generated deployment URL to verify that.

[libhide]

I too have noticed that the previews work for the website itself (ratik.in in my case) but fail to work for the blog or any of the nested pages.

[mwskwong]

Updated the OP

1. Updated next to the latest canary version
2. Added a branch that literally just removes the ppr flag, and the issue is not reproducible on it.
   • With PPR: https://http-500-when-visit-by-bot.vercel.app
   • Without PPR: https://http-500-when-visit-by-bot-git-feature-without-ppr-mwskwong.vercel.app

[mwskwong]

Vercel seems to finally be able to show the full log, so here is one example of it.

Error: Expected the resume to render <j> in this slot but instead it rendered <A>. The tree doesn't match so React will fallback to client rendering.
    at nq (/var/task/node_modules/next/dist/compiled/next-server/app-page-experimental.runtime.prod.js:12:66996)
    at nJ (/var/task/node_modules/next/dist/compiled/next-server/app-page-experimental.runtime.prod.js:12:73075)
    at nz (/var/task/node_modules/next/dist/compiled/next-server/app-page-experimental.runtime.prod.js:12:71240)
    at nq (/var/task/node_modules/next/dist/compiled/next-server/app-page-experimental.runtime.prod.js:12:69426)
    at nJ (/var/task/node_modules/next/dist/compiled/next-server/app-page-experimental.runtime.prod.js:12:73075)
    at nU (/var/task/node_modules/next/dist/compiled/next-server/app-page-experimental.runtime.prod.js:12:51918)
    at nq (/var/task/node_modules/next/dist/compiled/next-server/app-page-experimental.runtime.prod.js:12:67235)
    at nJ (/var/task/node_modules/next/dist/compiled/next-server/app-page-experimental.runtime.prod.js:12:73075)
    at nU (/var/task/node_modules/next/dist/compiled/next-server/app-page-experimental.runtime.prod.js:12:51918)
    at nq (/var/task/node_modules/next/dist/compiled/next-server/app-page-experimental.runtime.prod.js:12:67235) {
  digest: '1647279640'
}

[mwskwong]

Oh, adding www.partialprerendering.com as the reproduction.

https://www.linkedin.com/post-inspector/inspect/https:%2F%2Fwww.partialprerendering.com%2F

[libhide]

@mwskwong Any luck with fixing this? Seems to still be an issue :/

[mwskwong]

@mwskwong Any luck with fixing this? Seems to still be an issue :/

Nope. I don't think there is anything I can do from the user side, besides not using PPR.

[libhide]

@mwskwong Any luck with fixing this? Seems to still be an issue :/

Nope. I don't think there is anything I can do from the user side, besides not using PPR.

Yeah, same.

@leerob Any chance you'd know what's up with this issue?

[leerob]

As a reminder, PPR is still experimental. We are currently triaging and investigating other, higher requested bugs/features right now, but thank you for providing more details on this issue.

[wyattjoh]

Give the latest canary a shot, the issues you've experienced are likely to have been fixed recently.

[mwskwong]

Give the latest canary a shot, the issues you've experienced are likely to have been fixed recently.

No, it doesn't. I updated the reproduction's dependencies and deployed it accordingly

Also, the behavior can be easily verified by just toggling the ppr flag.

[wyattjoh]

Thanks for the details @mwskwong, I was able to identify and resolve the issue on Vercel's end. Let us know if the problem re-occurs by opening a new issue!

[libhide]

Can confirm that this is fixed for me too. Thanks, everyone involved!

[github-actions[bot]]

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.