Open castrix opened 1 year ago
Have you checked if you can reproduce this on a different system? Tried to repro this on two devices with no luck.
Have you checked if you can reproduce this on a different system? Tried to repro this on two devices with no luck.
Hi, thanks for looking at it.
I ran it on wsl2, I’ll try to dockerize it later and let you know if it’s still happening
Have you checked if you can reproduce this on a different system? Tried to repro this on two devices with no luck.
Hi, thanks for looking at it.
I ran it on wsl2, I’ll try to dockerize it later and let you know if it’s still happening
Awesome, I tried it on wsl2, win11, debian and arch without any similar issues.
Question, are you using the latest canary release locally? Cuz you're running a stable release on the reproduction repo.
Have you checked if you can reproduce this on a different system? Tried to repro this on two devices with no luck.
Hi, thanks for looking at it. I ran it on wsl2, I’ll try to dockerize it later and let you know if it’s still happening
Awesome, I tried it on wsl2, win11, debian and arch without any similar issues.
Question, are you using the latest canary release locally? Cuz you're running a stable release on the reproduction repo.
I tried on latest canary and latest stable, both behaving the same.
I used latest stable in repro repo because I first found the issue on latest canary and switched back to the latest stable to see if it will work, but it still happen.
Hi @JesseKoldewijn, I'm not sure why but I wasn't able to configure the correct docker for it, but I've updated the repro repo with Canary and also tested it on chrome, edge, firefox, and the issue still happens.
Here I added the attachment to show you the issue:
I'll take a look at it later today on multiple of my systems. Question, what browsers did you test this on?
I'll take a look at it later today on multiple of my systems. Question, what browsers did you test this on?
Chrome 114.0.5735.91
Edge 114.0.1823.37
Firefox 114.0
Hey man, the issue in this case is that by adding content to the layout in combination with running it as a client component you're getting a hydration error which doesn't seem to be handled all that well on nested layouts. (You can test this by changing the root layout.
Right now, if you have a nested layout that uses "use client" instead of a hydration error your whole tab locks up.
Sorry for the ping @leerob just curious if this is a known issue internally already. 👍
It doesn't look like this repro uses Turbopack, so removing this label. Are you still experiencing this issue with the latest version?
@castrix Hi! I guess I'm facing the same issue as you do; my case is that I'm fetching and revalidating data at layout
level; did you find a solution to this?
Is there anyone that was able to get a minimal repro up and running because I've not been able to find this behavior myself yet.
@JesseKoldewijn I believe you can try to create a small project with docker, max 1g ram memory and try to revalidate data on root layout; at least, for me it seems that the problem lays here
@JesseKoldewijn I guess the problem is the revalidating fetch logic in the main root (like the creator of this thread); do you know what could eventually the error be? In my case after 3/4 page refresh (it depends though), the tab freezes completely :/
@JesseKoldewijn tested on 13.5.6-canary.2 the issue that I reported is no longer happening.
@Emiliano-Bucci are u fetching it client side? since on the latest canary, there will be an error if you use useEffect/useState/"use client"
on layout
level, the error says that layout
is only for server-side.
Error: async/await is not yet supported in Client Components, only Server Components. This error is often caused by accidentally adding `'use client'` to a module that was originally written for the server.
@castrix Nope, I'm just fetching global data (header, footer, ecc) in the root layout and revalidating every 10s; I will try latest canary, thanks!
@castrix Sadly the freeze is still here :/
@castrix Sorry, but I'm new to App Rouer, and for some reason when querying and revalidating data in the Root layout the app completely freeze, even when rendering and empty page and just making a single query that is revalidated after N seconds; is this valid? I don't recall seeing anything about this in the docs but I'm start to think that this is not possible somehow.
If your tab locks up in your browser it should be a client side issue but then again, not really sure what exactly is happening.
Not sure what happen but my Chrome Tab also freeze everytime HRM updated
same, but only from time to time
Edit by maintainer bot: Comment was automatically minimized because it was considered unhelpful. (If you think this was by mistake, let us know). Please only comment if it adds context to the issue. If you want to express that you have the same problem, use the upvote 👍 on the issue description or subscribe to the issue for updates. Thanks!
Verify canary release
Provide environment information
Which area(s) of Next.js are affected? (leave empty if unsure)
App directory (appDir: true), CLI (create-next-app), Turbopack (--turbo)
Link to the code that reproduces this issue or a replay of the bug
https://github.com/castrix/nextjs-hmr-bug
To Reproduce
navigate the route to localhost:3000/home
switch to the editor, modify layout file in
/app/home/layout
switch to the browser, you can see that the tab freeze
Describe the Bug
When updating
layout
file while the dev server is running, the tab freeze, the HMR stuck, tab CPU high 50-100%, the page not reloading.next dev
script and innext dev --turbo
flag.Expected Behavior
Page reload, tab not freezing
Which browser are you using? (if relevant)
Chrome 114.0.5735.91
How are you deploying your application? (if relevant)
No response