nuxt: TypeError: Cannot read properties of null (reading 'parentNode')

Environment


  • Operating System: Linux
  • Node Version: v14.18.1
  • Nuxt Version: 3.0.0-27389502.88da719
  • Package Manager: yarn@1.22.17
  • Bundler: Vite
  • User Config: ssr
  • Runtime Modules: -
  • Build Modules: -

Reproduction

use this sandbox, Visit ${url}/organization/365824000000000003/template/new click on the “a” link then the “b” link and this error is thrown:

runtime-core.esm-bundler.js:38 [Vue warn]: Unhandled error during execution of scheduler flush. This is likely a Vue internals bug. Please open an issue at https://new-issue.vuejs.org/?repo=vuejs/core 
  at <Transition name="page" mode="out-in" > 
  at <Dashboard name="dashboard" > 
  at <AsyncComponentWrapper name="dashboard" > 
  at <NuxtLayout name="dashboard" > 
  at <BaseTransition mode="out-in" appear=false persisted=false  ... > 
  at <Transition name="layout" mode="out-in" > 
  at <RouterView > 
  at <NuxtPage> 
  at <App> 
  at <NuxtRoot>
runtime-dom.esm-bundler.js:35 Uncaught (in promise) TypeError: Cannot read properties of null (reading 'parentNode')
    at parentNode (runtime-dom.esm-bundler.js:35:30)
    at ReactiveEffect.componentUpdateFn [as fn] (runtime-core.esm-bundler.js:5109:17)
    at ReactiveEffect.run (reactivity.esm-bundler.js:160:29)
    at updateComponent (runtime-core.esm-bundler.js:4968:26)
    at processComponent (runtime-core.esm-bundler.js:4901:13)
    at patch (runtime-core.esm-bundler.js:4489:21)
    at patchKeyedChildren (runtime-core.esm-bundler.js:5262:17)
    at patchChildren (runtime-core.esm-bundler.js:5205:21)
    at processFragment (runtime-core.esm-bundler.js:4886:17)
    at patch (runtime-core.esm-bundler.js:4482:17)

Describe the bug

hooks page:start and page:finish don’t seem to fire on pages ${url}/organization/* and an error is thrown when using await in the <script setup> and then navigating to a new page.

I don’t know if this is due to the page structure or the the way the pages are set up. It’s taken me all day to get this error to reproduce and the only way I’ve gotten this to throw is with this folder structure and by

  • first visiting a page that doesn’t use await in the <script setup>
  • then visiting a page that does uses await
  • then by using vue-router to navigate to another page

Additional context

No response

Logs

No response

### Tasks

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 87
  • Comments: 292 (45 by maintainers)

Commits related to this issue

Most upvoted comments

i created a new nuxt application and transferred my files to the new application following the rules from the nuxt3 docs. problem fixed.

how ?

make sure when a component like NuxtLayout or NuxtPage is the root-node (first in template) to be wrapped within a div.

In my case this bug occurs when switching between pages with different layouts defined in definePageMeta, regardless the parent of NuxtPage element.

Yes, I was having my code like this

<template>
    <NuxtLayout>
        <NuxtPage />
    </NuxtLayout>
</template>

Wrapping the <NuxtLayout> with div fixed the issue.

The original reproduction now longer gives this error, when wrapping <NuxtPage>:

  <template>
+   <div>
      <NuxtPage />
+   </div>
  </template>

See https://codesandbox.io/s/immutable-fast-kv6yh0

FYI all: Vue v3.4.20 has released with this bug fixed.

This situation, which bothers everyone, seems to have been resolved with the new vue version.

Hi all. I had a problem when navigating between pages with changing layouts. I have little experience and I will be glad if you point out errors. I solved this problem for myself by wrapping <slot/> in <suspense>

~/layouts/example.vue

<template>
  <div>
    <p>Example layout</p>
    <suspense>
       <slot/>
    </suspense>
  </div>
</template>

Same issue. Wrapping NuxtLayout in a <div> doesn’t help.

Dynamic routes in question look like this:

  • Parent page: /pages/test/[id].vue
  • Child page: /pages/test/[id]/index.vue

Parent page has <NuxtPage :something="something" /> wrapped in a <div>.

I can navigate to the dynamic route twice, then on the third time, I get the [Vue warn]: Unhandled error during execution of scheduler flush. warning and the Uncaught (in promise) TypeError: Cannot read properties of null (reading 'parentNode') error.

This issue happens when I switch pages that related to different layouts

Just to inform the thread, this could be our hero: PR: https://github.com/vuejs/core/pull/10184 ISSUE: https://github.com/vuejs/core/issues/10098

@alexovn you’re right, the patch seems to solve the issue. I completely forgot to try it earlier. 😅 Thanks!

For anyone using pnpm: run pnpm patch @vue/runtime-dom and then change the line described here: https://github.com/vuejs/core/issues/6463#issuecomment-1442075520

multiple clicks on <NuxtLink> on nuxt 3.8.2 and vue 3.3.10 still not fixed

Reopening as this was wrongly closed. It is, however, an upstream Vue bug related to transitions and not a Nuxt bug.

Hey ~ I made two contrasting Stackblitz mini reproduction

The problem seems to be solved on vue 3.4.0-beta.3

The same router.push() is triggered multiple times,There is still a difference without vue 3.4.0-beta.3 installed

Now, use new version: nuxt 3.8.2 + vue 3.4.0-beta.3 , the problem is solved !

https://stackblitz.com/edit/github-2vsgq3-lfvt5w?file=package.json,src%2Fpages%2Findex.vue

Dec-19-2023 11-57-27

Reproduction for vue 3.4.0-beta.3 is not installed, is not work:

https://stackblitz.com/edit/github-2vsgq3-bx6x1z?file=package.json,src%2Fpages%2Findex.vue

Dec-19-2023 12-10-20

Vue 3.3.10 was just released 🎉

As this issues was linked to the issue I mentioned, there is a good chance this issue could be resolved by updating Vue to v3.3.10. Would anyone affected please verify?

Any news? The wait is getting long 😦

We’re encountering same issue with Nuxt 3.8.0 (SSR). This issue tends to arise when users with slow internet connections double-click a NuxtLink before the new page has finished fetching its content. The application/website becomes unresponsive, requiring a hard refresh to restore functionality.

You can fix this by patching your local Vue in these two places: https://github.com/nuxt/nuxt/pull/22947#discussion_r1313990560

Tho we still not yet located the root cause in a vanilla Vue project to fix it.

My local works fine, but when I deploy on dev(firebase), I got the same error whenever I route to another page.

We also are still affected by this problem and would like to see this issues re-opened.

This is still a Vue upstream bug and not a Nuxt issue.

Fixed with :

definePageMeta({
  layoutTransition: true,
});

You can test Vue 3.4.0 beta setting this in your package.json:

  "resolutions": {
    "vue": "npm:vue@3.4.0-beta.3"
  }

Then re-installing the dependencies (you can remove your lock file and node_modules to be sure).

Stackblitz example: https://stackblitz.com/edit/nuxt-vue-3-4-beta?file=app.vue

It seems to fix the issue on my local reproduction when using navigateTo within Suspense (after some await in a page for example)

I solved this problem by using <client-only></client-only> on the outer layer of sub components

Hi everyone. this problem is not related with Nuxt 3.x . It’s Vue internal bug and I think the responsible package is @vue/runtime-dome 3.4.15 . The only thing you can do is downgrading vue version to 3.3.x (it will also downgrade @vue/runtime-dom) and the error will be gone trust me. (Do not forget removing the caret “^” from the package.json where you define the vue version. Otherwise your package manager will update your vue version to the latest) Before you do that delete your .nuxt folder and node_modules and install everything from scratch.

Check this out

It seems that the issue will be completely RESOLVED in the Vue 3.4.0. Currently it closed in Vue 3.4.0-beta.1. So everyone should just wait before release

https://github.com/vuejs/core/blob/minor/CHANGELOG.md#340-beta1-2023-12-13

https://github.com/vuejs/core/pull/7290

@danielroe @anburocky3 I ran into this problem too, adding div wraps to NuxtPage didn’t fix it either. Router. push or NuxtLink can be used to jump to the page normally. However, if you jump to the page after refreshing the browser, a parentNode problem will occur. Finally, refresh the browser to display the page.

Any reproduction steps? Try to upgrade to nuxt3 latest and retry it.

Finally, I close SSR and solve this problem.

Just an update on my part after two weeks, related to what I posted in the lower bit of https://github.com/nuxt/nuxt/issues/13309#issuecomment-1746742348 .

Since this comment we run our App with the patched vue-package, using the aforementioned solution https://github.com/vuejs/core/issues/6463#issuecomment-1442075520 .

So far this “just works” without any noticeable sideffects, neither in dev nor in prod builds. Our sentry logging doesn’t show anything out of ordinary either. Of course it’s not a final solution, and I still don’t feel super comfortable about it. In hindsight I probably should’ve patched this with a try/catch and log the error so we’re not getting too comfy with just using this patch, as the patch just treats the symptoms of this bug by quasi ignoring it. But it is what it is now.

All in all it seems to be the lesser evil at this point - better than downgrading or checking every combination of components that include async/suspense/transitions and so on.

Well, that’s it for now, looking forward to the Vue-Teams work on this.

The problem continues in vue 3.3.10, I did the tests.

@tolgahanbeyazoglu

It’s strange that so many users are having problems and it’s not resolved.

It’s because it is an upstream bug in Vue, not Nuxt’s, as Daniel said here. So we better be patient until the Vue team release this fix.

Just note that the current fix is not complete. It work only when you are not using transitions. We are still investigating

@Jupriadi Adding vue v3.4.8 solved it in my case

I also was dealing with this issue, fixed it wrapping all the <NuxtLayout /> used on my pages with a <div>.

  • using Nuxt (3.10.1)

@agracia-foticos is it different than https://github.com/nuxt/nuxt/issues/25214 ? Also, when a vue version update causes an issue, it is rarely a Nuxt issue.

@danielroe can you considerate reopen the issue? or maybe we can create another… thanks in advance

So what should I do to get rid of the error? I get it when navigating routes via NuxtLink

Update to the latest Vue version v3.4.13.

I can confirm this PR fixes all 3 of my layout issues - awesome work @antfu

Fixed with an edge release. Just add this inside the package.json: “nuxt”: “npm:nuxt3@pr-21450”

And be sure to run nuxi upgrade --force for clearing the cache

Fixed with an edge release. Just add this inside the package.json: “nuxt”: “npm:nuxt3@pr-21450”

And be sure to run nuxi upgrade --force for clearing the cache

In version 3.4.8, everything is working perfectly here, however, when updating to 3.4.14, the error returned.

This is an upstream Vue bug, not a Nuxt bug. The reason earlier versions of Nuxt exhibit this behaviour is that the particular condition required for the upstream bug to manifest were not met.

@danielroe version: 3.6.5 Reproduce example: https://stackblitz.com/edit/github-2vsgq3?file=src%2Fpages%2Findex.vue&file=src%2Fpages%2Fasync-page.vue

When you quickly double click the To Async Page button (i.e. quickly click), you can reproduce the error:

Aug-08-2023 00-39-02

I’m suffering from this issue too. As for my situation, this issue reproduces in production environment, but doesn’t in local development environment.


I find the reason that why “this issue reproduces in production environment, but doesn’t in local development environment.”. The version of Nuxt is not same in production and development environment, due to the two environments use different package manager ( npm / pnpm ).

In development, the version is 3.6.1, which doesn’t contain this issue, however in production, the version is 3.6.5, which contain this issue. Thus afert I downgrade to 3.6.1, the issue is not happening any more.

I think my issue should be tracked in https://github.com/nuxt/nuxt/issues/22900 .

I am also having this error, was there any resolution reached? my pages/ looks like this:

pages
└── [group]
    ├── index.vue
    └── [id].vue

and my app.vue is this: (the <v-xxx> components are of the vuetify library)

<v-app>
    <Header />
    <v-main>
        <v-container class="my-4">
            <NuxtLayout>
                <NuxtPage />
            </NuxtLayout>
        </v-container>
    </v-main>
    <Footer />
</v-app>

When I generate my app (target: static) and try to navigate to a page/[group] from the home page, this error appears and navigation fails. If I then refresh, I can navigate freely across all of my application, until I refresh again while on the home page.

We also are still affected by this problem and would like to see this issues re-opened.

Nuxt 3.10.1 is not a fix for this issue.

Tips like adding extra <div>s or changing the HTML structure with a different layout and so on are non-solutions for us because we don’t want to change the source code we want to have as a replacement for a problem fix (combat symptoms).

Out tests strengthen the hypothesis that the Vue.js core library is the culprit. Adding vue@v3.4.8, effectively overwriting the version brought in by Nuxt (which is newer) fixes the problem for us.

Is this problem known to the Vue.js folks and is that problem on their roadmap already?

This error happens again after upgrade vue from 3.4.1 to 3.4.15. Happens when changing routers. Nuxt version: 3.10.0.

image

I tried all versions 3.4.8-14 in reverse order, arriving at a working copy at 3.4.8.

using Vue v3.4.13 doesn’t fix the problem for me, but wrapping NuxtLayout inside div or just by adding comment above NuxtLayout fixed the problem somehow see this reproduction on stackblitz

please check #25214

Same here. This is taking so long to fix and causing so much issues for my clients/users that I’m at the point of considering trying to disable double-clicks and forcing hard refreshes when this error occurs. ☹️

Just add temporary patch to ‘@vue/runtime-dom’ and wait until problem will be fixed. I did it and no more worries

As mentioned also in the issue #23814, it happens also when you quickly click more time on a NuxtLink

Any advance?

@danielroe version: 3.6.5 Reproduce example: https://stackblitz.com/edit/github-2vsgq3?file=src%2Fpages%2Findex.vue&file=src%2Fpages%2Fasync-page.vue

When you quickly double click the To Async Page button (i.e. quickly click), you can reproduce the error:

Aug-08-2023 00-39-02

@antfu @danielroe PR https://github.com/nuxt/nuxt/pull/21450 successfully fixes error on my side where I am navigating from one page to another with different layout.

Can anyone provide a few more minimal reproductions, if you still have the error with npm:nuxt3@pr-21450? Thanks

Same here, I had no problem with all previous versions of Nuxt, but with Nuxt 3.5 I’m starting to have these errors :

  • No problem navigating between pages that have the same layout
  • When navigating (with <NuxtLink /> or navigateTo) from a page to another with another layout, I have this error with a blank page

Reverting to 3.4 for now.

I upgraded to 3.2.2, bug still exists. Also tried to wrap NuxtLayout to a div, didn’t fix the problem either. It doesn’t happen in dev, because I configured SSR only for prod.

ssr: process.env.NODE_ENV !== 'development'

Problem: I use Element Plus component library and Nuxt3 framework, and I also met the parentNode error.

Solved: According to the Element Plus official document, tags such as <el-tooltip> need to be wrapped by <client-only>, and then I solved the problem.

I have same issue in one of my project. I just created new Nuxt 3 project with two basics layouts for the test. Here’s my few files :

app.vue

<template>
  <div>
    <NuxtLayout>
      <NuxtLoadingIndicator />
      <NuxtPage />
    </NuxtLayout>
  </div>
</template>

layouts/default.vue

<template>
  <div>
    <Header></Header>
  </div>

  <div>
    <slot></slot>
  </div>
</template>

layouts/custom.vue

<template>
  <div>
    <CustomHeader></CustomHeader>
  </div>

  <slot></slot>
</template>

components/Header.vue

<template>
  <div>
    <NuxtLink to="/">Home</NuxtLink>
    <NuxtLink to="about">About</NuxtLink>
  </div>
</template>

components/CustomHeader

<template>
  <div>
    <NuxtLink to="/">Home</NuxtLink>
    <NuxtLink to="about">About</NuxtLink>
    <NuxtLink to="https://www.google.com" target="_blank">Google !</NuxtLink>
  </div>
</template>

pages/index.vue

<template>
  <div>
    Hello World !
  </div>
</template>

<script setup>
definePageMeta({
  layout: 'default'
})
</script>

pages/contact.vue

<template>
  <div>
    Contact us
  </div>
</template>

<script setup>
definePageMeta({
  layout: 'custom'
})
</script>

Just changing from one layout to the other cause the bug, except that I haven’t any errors in console 🤡

The root cause seems to be the layout change.

When using the overriding layout, it works (https://v3.nuxtjs.org/guide/directory-structure/layouts#overriding-a-layout-on-a-per-page-basis). On the other hand, the transition between the pages is perceptible…

I’m really not a nuxt expert, so hopefully my comment will be helpful to someone in finding out the real problem.

apart from this solution provided by @danielroe

  <template>
+   <div>
      <NuxtPage />
+   </div>
  </template>

… i found that components having another component as their root-element also was cause of this problem. wrapping these with a html-element (e.g. div) solved the problem for me.

Don’t now if it is helpful, but I experienced some similar errors while developing our app. In the end it was caused by a transition component as the root component in the template. Navigating between routes sometimes caused the parentNode issue.

Also our pages setup looks a lot like yours, so maybe it is helpful 😃

Indeed, it works with 3.4.8.

Yeah! with 3.9.1 it happens when you navigate to a page that has a different layout from where you landed. For example if the / is using home layout and blog is using blog layout, then if you land on / and click on /blog link the error appears and the subsequent navigation does not work.

faced the same issue in nuxt 3.9.1 and fixed by upgrading the vue version to 3.4.13. i don’t know if it’s gonna work for you.

Everyone, Vue 3.4.0-beta.2 is published on npm. If feasible you could try out that version of Vue in your project and report if the error is gone, using the many possible reproduction instruction already given in this thread 🚀

@tolgahanbeyazoglu

Do you have a workaround until the vue team produces a solution?

You can use ssr: false for the buggy routes (using route rules) as a temporary workaround, or you can downgrade Nuxt to 3.6.1 if ssr: false is not an option.

I believe this is certainly a serious issue, and these two issues #23232 #22955 might be related to this.

I don’t know why, but in my case it was due to definePageMeta in my pages

definePageMeta({
  layout: 'default',
});

my solution was set layout to false and use setPageLayout


setPageLayout('my-page');

definePageMeta({
  layout: false,
  header: {
  //  I can use custom metas...
  },
});

This is exactly the problem I’m having. the user will experience a bad outcome

258871960-81a40690-9ae2-44c0-8efa-1597fb1808c2

@bombasticseahorse Let’s track that in https://github.com/nuxt/nuxt/issues/22900 instead. It seems this can also be caused without transition, though I suspect it’s still the same root cause in.

Hi, I have the same issue with the latest version of Nuxt. I found a solution !

If I replace useAsyncData by useLazyAsyncData, it works !

Ex :

This code generate the “parentNode” error :

const {
  data: livre,
  pending,
  error,
} = await useAsyncData("", async () => {
  const livre = await client.getByUID("livre", props.slice.primary.livre.uid);
  return livre;
});

Not this one :

const {
  data: livre,
  pending,
  error,
} = await useLazyAsyncData("", async () => {
  const livre = await client.getByUID("livre", props.slice.primary.livre.uid);
  return livre;
});

@gokhantaskan This is a Vue bug with Transition. Follow https://github.com/vuejs/core/issues/8105 for updates.

I have this PR on 4 different production setups running fine - IMO due to the impact of this bug I’d vote this is safe to merge

It maybe a problem with configs, I found a fix for all Vuetify users. If you are using Vuetify and SSR also make sure SSR is turned on in Vuetify plugin config and the issue is gone.

We had the same situation as @jbreuil described:

When there is ref used in the loop:

   <div
      v-for="(item, index) in items"
      :key="index"
      ref="something"
    >
      bla bla
    </div>

and layout is changed after routing

<script setup lang="ts">
definePageMeta({
  layout: "test3",
});
</script>

Error appears. Everything works perfectly if ref or definePageMeta is removed. So it looks like that two pieces of code must be triggered to reproduce the error

Please someone tell me, how is this framework production ready when something as simple as a route change has such a bug.

Same problem in Nuxt 3.5, error emitted when page navigate.

As

Problem: I use Element Plus component library and Nuxt3 framework, and I also met the parentNode error.

Solved: According to the Element Plus official document, tags such as <el-tooltip> need to be wrapped by <client-only>, and then I solved the problem.

As zc1342303 said; Look for external libraries and wrap a <client-only> tag around them. I used Headless UI and this was also needing a <client-only> tag.

I had this problem with this configuration image

To fix it i transferred [id]/main.vue and [id]/media.vue to components and remove [id] folder. May be it will help somebody.

There was the same problem. At first it was solved the same way. Then I realised that this solution was not suitable. It took me a long time to figure out what the problem was. It turned out that when switching from one page with nested pages to another page with nested pages, <NuxtPage /> didn’t seem to have time to change. This causes the props to be undefined and everything crashes. Invented this:

const nestedShowed = ref(true);
const router = useRouter();
router.beforeEach((to, from) => {
  if (to.fullPath.split("/")[1] !== from.fullPath.split("/")[1]) {
    nestedShowed.value = false;
  }
});
<NuxtPage v-if="nestedShowed" :club="mainInfo" />

This disables <NuxtPage /> first, and only then goes to the new page.

Translated with www.DeepL.com/Translator (free version)

Got the same error. Fixed by adding vuetify wrapper tag <v-no-ssr> around <v-snackbar>:

But it took a long time to find this place

 <v-no-ssr>
      <v-snackbar v-model="snackbar.show" top multi-line :timeout="snackbar.timeout" :color="snackbar.color">
        {{ snackbar.text }}
        <template #actions>
          <v-btn color="secondary" @click="snackbar.show = false">
            Close
          </v-btn>
        </template>
      </v-snackbar>
    </v-no-ssr>

I managed to fix it by upgrading and fixing a bunch of dependencies. Too bad I cannot say what my changes were because I lost track at some point.

@danielroe @anburocky3 I ran into this problem too, adding div wraps to NuxtPage didn’t fix it either. Router. push or NuxtLink can be used to jump to the page normally. However, if you jump to the page after refreshing the browser, a parentNode problem will occur. Finally, refresh the browser to display the page.

Any reproduction steps? Try to upgrade to nuxt3 latest and retry it.

Finally, I close SSR and solve this problem.

i am using nuxt3 but i am still getting this error

Hi all. I had a problem when navigating between pages with changing layouts. I have little experience and I will be glad if you point out errors. I solved this problem for myself by wrapping <slot/> in <suspense>

~/layouts/example.vue

<template>
  <div>
    <p>Example layout</p>
    <suspense>
       <slot/>
    </suspense>
  </div>
</template>

**helped for nuxt 3.10.2 **

брат ты легенда

Probably one of these 4 changes could be the cause of this error returning in Vue Core:

https://github.com/vuejs/core/blob/main/CHANGELOG.md#349-2024-01-11

The error is still in vue 3.4.15

It has to be:

Same issue occurred. Vue 3.4.8 works fine.

With 3.4.14 the return returned image

@Youhan agree. just another point, but I was facing it in pages sharing the same layout as well.

Same here. This is taking so long to fix and causing so much issues for my clients/users that I’m at the point of considering trying to disable double-clicks and forcing hard refreshes when this error occurs. ☹️

It’s strange that so many users are having problems and it’s not resolved. Maybe the conversation is going in the wrong direction. It should proceed in the question and answer section.

We are having similar issue with nuxt 3.8.0 that doesn’t happen in 3.7.4.

We have a component in a nuxt module with two versions, one for server without any additional logic and one for client. The logic is loaded on demand because it is quite heavy and this way we can make server files lighter.

To make work nuxt 3.8 we should make only one file and this way it works.

It doesn’t break if it is not SSR, navigating from other page.

@Meleemaru2k More or less the same I did, before giving up. Wild that it takes this much effort to fix usage of two major frameworks.

Interestingly, as we encountered this issue, we were using the ssr: false build of nuxt (cause we don’t need SSR). Once we switched to ssr: true, the issue went away.

@danielroe @ilyaDegtyarenko I had a similar issue removing page-key solved it for me, Strange! <NuxtPage page-key="static" /> to <NuxtPage />

3.7.0 still there

@FullTag Thank you very much for your solution.

The first approach, using shallowRef, worked very well.

For the second approach, typescript complains that:

Type 'undefined' is not assignable to type 'Ref<HTMLSpanElement[] | null>'

but it also works correctly if we change it to:

const slides = ref<HTMLElement[] | null>(null)
onBeforeUnmount(() => {
  slides.value = null
})

Good job @antfu, I successful sent this version into production

Maybe it has something to do with vuejs/core#6463

Im surely not anyone boss ahah, but could anyone in the nuxt team put more effort into that? That makes nuxt not usable with layouts/real world applications. We have reproduction links and everything to point where the bug could be.

Please someone tell me, how is this framework production ready when something as simple as a route change has such a bug.

It surely needs to be fix asap, but does not mean this framework is not production ready

Do you prefer building apps where users cannot change their route on page refresh?

Just change to version 3.4.3 buddy and it works

This problem has existed for a long time. I have this problem in the beta version of nuxt3. Combined with this issue, it seems that there are various reasons for this problem, and the solutions are also different. You can try to find out if there is a suitable solution in this issue

I also have this problem, after some tests I encountered the solution in nuxt.config.ts

export default defineNuxtConfig({
  app: {
    pageTransition: false,
    layoutTransition: false,
  }
});

I’ve been getting this issue today.

To reproduce I have 2 pages, one uses the default layout, the second has layout set to false in definePageMeta.

If I refresh the page to the one without the layout, I can navigate to the one with the layout, and back again without issue. If I refresh the page to the one with the default layout, I then cannot navigate to the page where the layout is set to false.

Hopefully, this gets fixed so that we don’t have to use messy workarounds…

I’m seeing this error with the above solution from @codeflorist in rc-9:

[Vue warn]: Unhandled error during execution of setup function 
  at <RouterView name=undefined route=undefined >
[nitro] [dev] [unhandledRejection] TypeError: Cannot read properties of null (reading 'parent')

My app.vue component:

<template>
  <div>
    <NuxtPage />
  </div>
</template>

My pages/index.vue component:

<template>
  <div>
    <h1>Index page</h1>
  </div>
</template>

<script setup lang="ts"></script>

That’s the only changes I have made to the base rc-9 installation …

Plus,

You can meet with this issue while using nested layouts. You have to append page-key attribute to it.

@danielroe @anburocky3 I ran into this problem too, adding div wraps to NuxtPage didn’t fix it either. Router. push or NuxtLink can be used to jump to the page normally. However, if you jump to the page after refreshing the browser, a parentNode problem will occur. Finally, refresh the browser to display the page.

Hello, after upgrading to 3.10.0 have the same problem.

Fixed with :

definePageMeta({
  layoutTransition: true,
});

This worked for me as well, but resulted in a blank page between transition.

Finally I wrapped all of the NuxtLayout elements in my app in a div and that fixed it for me without the blank page in between. So weird.

This issue still exist in a big way. It does appear that the culprit has to do with the tag. Does anyone plan to fix this?

I can confirm that downgrading to Vue 3.3.13 works just fine and the error is resolved.

Hi guys.

In my case, this error appeared during the layout change. My project was saved by installing this vue version:

npm i vue@v3.4.8

Wrapping all NuxtLayouts in divs throughout the app helped me. Look if some pages in your application use NuxtLayout, not just the home page.

So what should I do to get rid of the error? I get it when navigating routes via NuxtLink

I removed page transitions and it’s working again. What’s strange is that I could not reproduce my issue locally in dev/prod mode but only seems to happen when CloudFlare distributes the website. Probably because of the latency issue explained. It just happened randomly though. It used to work a couple days ago still normally with no issue. https://github.com/BeamMW/beam-web/pull/112

I cheered too soon. Since deploying the patch to production I have these errors popping up in production:

NotFoundError: Failed to execute 'insertBefore' on 'Node': The node before which the new node is to be inserted is not a child of this node.
  at nodeOps.insert(../../../node_modules/.pnpm/@vue+runtime-dom@3.3.8_patch_hash=uro7otho7pcnt3mc2la72dimwi/node_modules/@vue/runtime-dom/dist/runtime-dom.esm-bundler.js:10:12)
  at move(../../../node_modules/.pnpm/@vue+runtime-core@3.3.8/node_modules/@vue/runtime-core/dist/runtime-core.esm-bundler.js:6196:9)
  at move(../../../node_modules/.pnpm/@vue+runtime-core@3.3.8/node_modules/@vue/runtime-core/dist/runtime-core.esm-bundler.js:6169:7)
  at move(../../../node_modules/.pnpm/@vue+runtime-core@3.3.8/node_modules/@vue/runtime-core/dist/runtime-core.esm-bundler.js:6169:7)
  at move(../../../node_modules/.pnpm/@vue+runtime-core@3.3.8/node_modules/@vue/runtime-core/dist/runtime-core.esm-bundler.js:6169:7)
  at activeBranch.transition.afterLeave(../../../node_modules/.pnpm/@vue+runtime-core@3.3.8/node_modules/@vue/runtime-core/dist/runtime-core.esm-bundler.js:1433:15)
  at performRemove(../../../node_modules/.pnpm/@vue+runtime-core@3.3.8/node_modules/@vue/runtime-core/dist/runtime-core.esm-bundler.js:6306:20)
  at el[leaveCbKey](../../../node_modules/.pnpm/@vue+runtime-core@3.3.8/node_modules/@vue/runtime-core/dist/runtime-core.esm-bundler.js:2245:9)
  at finishLeave(../../../node_modules/.pnpm/@vue+runtime-dom@3.3.8_patch_hash=uro7otho7pcnt3mc2la72dimwi/node_modules/@vue/runtime-dom/dist/runtime-dom.esm-bundler.js:157:13)
  at resolve(../../../node_modules/.pnpm/@vue+runtime-dom@3.3.8_patch_hash=uro7otho7pcnt3mc2la72dimwi/node_modules/@vue/runtime-dom/dist/runtime-dom.esm-bundler.js:188:29)
  at whenTransitionEnds(../../../node_modules/.pnpm/@vue+runtime-dom@3.3.8_patch_hash=uro7otho7pcnt3mc2la72dimwi/node_modules/@vue/runtime-dom/dist/runtime-dom.esm-bundler.js:267:12)
  at <anonymous>(../../../node_modules/.pnpm/@vue+runtime-dom@3.3.8_patch_hash=uro7otho7pcnt3mc2la72dimwi/node_modules/@vue/runtime-dom/dist/runtime-dom.esm-bundler.js:199:11)
  at sentryWrapped(../../../node_modules/.pnpm/@sentry+browser@7.85.0/node_modules/@sentry/browser/esm/helpers.js:90:17)

I don’t have any errors on production. Did you patch all files? You need to patch all files in runtime-dom directory that have parentNode: (node) => node.parentNode prop

runtime-dom.cjs.js runtime-dom.cjs.prod.js runtime-dom.esm-browser.js runtime-dom.esm-bundler.js runtime-dom.global.js

I cheered too soon. Since deploying the patch to production I have these errors popping up in production:

NotFoundError: Failed to execute 'insertBefore' on 'Node': The node before which the new node is to be inserted is not a child of this node.
  at nodeOps.insert(../../../node_modules/.pnpm/@vue+runtime-dom@3.3.8_patch_hash=uro7otho7pcnt3mc2la72dimwi/node_modules/@vue/runtime-dom/dist/runtime-dom.esm-bundler.js:10:12)
  at move(../../../node_modules/.pnpm/@vue+runtime-core@3.3.8/node_modules/@vue/runtime-core/dist/runtime-core.esm-bundler.js:6196:9)
  at move(../../../node_modules/.pnpm/@vue+runtime-core@3.3.8/node_modules/@vue/runtime-core/dist/runtime-core.esm-bundler.js:6169:7)
  at move(../../../node_modules/.pnpm/@vue+runtime-core@3.3.8/node_modules/@vue/runtime-core/dist/runtime-core.esm-bundler.js:6169:7)
  at move(../../../node_modules/.pnpm/@vue+runtime-core@3.3.8/node_modules/@vue/runtime-core/dist/runtime-core.esm-bundler.js:6169:7)
  at activeBranch.transition.afterLeave(../../../node_modules/.pnpm/@vue+runtime-core@3.3.8/node_modules/@vue/runtime-core/dist/runtime-core.esm-bundler.js:1433:15)
  at performRemove(../../../node_modules/.pnpm/@vue+runtime-core@3.3.8/node_modules/@vue/runtime-core/dist/runtime-core.esm-bundler.js:6306:20)
  at el[leaveCbKey](../../../node_modules/.pnpm/@vue+runtime-core@3.3.8/node_modules/@vue/runtime-core/dist/runtime-core.esm-bundler.js:2245:9)
  at finishLeave(../../../node_modules/.pnpm/@vue+runtime-dom@3.3.8_patch_hash=uro7otho7pcnt3mc2la72dimwi/node_modules/@vue/runtime-dom/dist/runtime-dom.esm-bundler.js:157:13)
  at resolve(../../../node_modules/.pnpm/@vue+runtime-dom@3.3.8_patch_hash=uro7otho7pcnt3mc2la72dimwi/node_modules/@vue/runtime-dom/dist/runtime-dom.esm-bundler.js:188:29)
  at whenTransitionEnds(../../../node_modules/.pnpm/@vue+runtime-dom@3.3.8_patch_hash=uro7otho7pcnt3mc2la72dimwi/node_modules/@vue/runtime-dom/dist/runtime-dom.esm-bundler.js:267:12)
  at <anonymous>(../../../node_modules/.pnpm/@vue+runtime-dom@3.3.8_patch_hash=uro7otho7pcnt3mc2la72dimwi/node_modules/@vue/runtime-dom/dist/runtime-dom.esm-bundler.js:199:11)
  at sentryWrapped(../../../node_modules/.pnpm/@sentry+browser@7.85.0/node_modules/@sentry/browser/esm/helpers.js:90:17)

Although it is mostly caused by VUE, was there no solution found on the nuxt side in versions 3.8.0 or 3.8.1 ?

For me, the issue started occuring when upgrading from 3.6.5 to 3.8.0. I also get the Vue internals warning. The warning occurs for one specific instance of a component which worked fine before and still works in all other places it’s being used so I’m pretty sure there’s nothing wrong with the component itself. Reverting back to 3.7.4 solved this specific occurence for me.

no, only version <=3.6.5 can use, other is not work

I’m just stating what worked for me. I had this issue with 3.8.0 and not with 3.7.4. It’s a complex issue so it’s not that weird that a work around that works in one case doesn’t work for everybody.

@gertjanjansen We updated to Yarn 3 since it has built-in patch capabilities - you simply create the patch as described in the docs, it automatically updates your packages.json, and then you commit the patch and updates packages.json (and lockfile) to your repo. The patch will be applied in package installs, no special steps required.

Can’t help with much else in this regard, was the first time I needed to patch a package for me too, sorry.

@danielroe Do you have a workaround until the vue team produces a solution?

I got a similar error.

I delete all the content in the component and when redirecting from index.vue of the pages using nuxt-link.

<nuxt-link :to="{ name: 't-slug', params: { slug: item.slug } }">
{{item.title}}
</nuxt-link>

Then I clicked on the link and it worked, but when I clicked back in the browser and clicked on the link again, an error appeared.


chunk-NCTPXXLD.js:9157 Uncaught (in promise) TypeError: Cannot read properties of null (reading 'parentNode')
     at parentNode (chunk-NCTPXXLD.js:9157:30)
     at ReactiveEffect.componentUpdateFn [as fn]

and

Uncaught (in promise) TypeError: Cannot read properties of null (reading 'subTree')

I have read and reread and found the error message in this topic.

The answers didn’t work for me until I solved it by changing the path with :external=“true”

<nuxt-link :to="{ name: 't-slug', params: { slug: item.slug } }" :external="true">
{{item.title}}
</nuxt-link>

It works for me. Leave it for someone in need. I still don’t understand the cause of the problem, but now the error is gone.

I also facing the same issue !!! I have 2 pages home. Vue & explore.vue

I am using useAsyncData and fetching the data from API --> it works fine next I moving to explore.vue via <NuxtLink> and come back to home.vue after that I multi clicking on the same home.vue it’s generating an error

Unhandled error during execution of scheduler flush. This is likely a Vue internals bug.

so i switched the approach of data fetching from useAsyncData to useLazyAsyncData it work fine for me.

Alright, maybe important that we do use SSR - and ClientOnly is not an option for us (which worked for others here, which is in stark contrast to what you described…mhm). Gonna edit my comment.

You can fix this by patching your local Vue in these two places: #22947 (comment)

Tho we still not yet located the root cause in a vanilla Vue project to fix it.

FYI: This sadly didn’t seem to fix this issue for me. Also first time patching a package, so i made REALLY sure it’s actually working and added some console logs (because i’m a professional) into it.


Also maybe helpful, a list of things I’ve tried so far without too much detail. All of this with SSR:

  • using onBeforeUnmounted instead of onUnmounted in all components
  • removing components with a teleport
  • commenting out basically the whole page-content (which at some point, if there were just layouts left, it LOOKED like it was stable then, but I highly doubt it.)
  • suspensible on all the suspense things
  • commenting out most stuff in the layout components
  • pageTransition & layoutTransition false in nuxtConfig
  • removing the aforementioned supense-wrapper with the slot
  • adding a div around the slot
  • adding or removing wrapper-divs here and there in some components
  • giving NuxtPage a static key / or custom key
  • …and probably some other things along the way

However: https://github.com/vuejs/core/issues/6463#issuecomment-1442075520 This seemingly works - but I have no idea if that’s “safe” to use, at least for a while. Any ideas on that?

My last option would be to downgrade to 3.5.3/3.4.3 or to just rip out all the layouts/suspense stuff and rework it into a custom solution. But I’d really love to not do either.

While debugging, I just stumbled upon a workaround I totally forgot I implemented at some point.

Suspense doesnt seem to properly work anymore since the Nuxt upgrade from 3.5.3 to 3.6.5 Wrapping the suspense in a compenent with a slot seems to fix this issue. Not needed if the page cannot be loaded from SSR or is already in component with a slot

<template>
  <slot />
</template>

I can’t remember the issue fully anymore, might’ve been suspense not properly triggering it’s fallback template or page content partially rendering twice. Or, and I think that’s it, that the Fallback-Template always showed (even on a fully rendere page).

This might’ve also been the point where the layout issues started happening, which neither me or anyone in my team have had noticed at this point (we have few layout switches, and even as of now they only fail “sometimes”). Would make sense, given that nobody on the team can pinpoint when this started happening. It’s pretty much like the comment above shows, sometimes it works, until it doesn’t: https://github.com/nuxt/nuxt/issues/13309#issuecomment-1742843053

So, this might help, or maybe not, but I thought it might be worth posting.

For me, change <NuxtPage :page-key="$route.fullPath" /> to <NuxtPage :page-key="route => route.fullPath" /> and it works.

This solution could cause duplicate requests if any of the page components use useFetch

Hey, just offering this reproduction in case it helps identify the root cause.

I have a login page, if users are “unauthenticated” and on login, you get the error described, everything is fine when you refresh the page though. The code seems to follow all suggestions, let me know if I’m missing something.

This is the best I could do to mimic what was going on in my app without any transitions (upstream vue bug) or multiple navigations (#22900). It’s a bit hacky with the auth though 🤣

to see it…

Click login, see a blank page and error in the console, refresh, see the page rendered.

Same issue

Hi, I had the same issue with the latest version of Nuxt. What is the current progress

Seems like they won’t be addressing the issue based on @manniL the last comment.

But I don’t know exactly what could be “hydratation errors” - maybe better documented nuxt fetching utils and lifecycle would help to solve this issue people are having. Or just show us the proper fix on pdsuwwz reproduction?

Hey again 👋🏻

  1. If you use transitions, this is most likely related to a vue bug. Nothing the Nuxt team can do here I’m afraid. Follow https://github.com/vuejs/core/issues/8105 in this case
  2. If you do not use transitions and see this bug in production, this can also be a hydration issue and is usually a userland problem.

Please refrain from posting “Still there in version X.Y.Z”


Faced this issue after upgrading from 3.4.3 to 3.6.5. Downgrading back helped me.

I have await in pages/[slug].vue and use definePageMeta.

I’m on Nuxt 3.6.5 and seem to have this bug too.

this is the warning

[Vue warn]: Unhandled error during execution of scheduler flush. This is likely a Vue internals bug. Please open an issue at https://new-issue.vuejs.org/?repo=vuejs/core 
  at <RouteProvider key="/" vnode= {__v_isVNode: true, __v_skip: true, type: {…}, props: {…}, key: null, …} route= {fullPath: '/', path: '/', query: {…}, hash: '', name: 'index', …}  ... > 
  at <RouterView name=undefined route=undefined > 
  at <NuxtPage> 
  at <App key=3 > 
  at <NuxtRoot>

and these are the two errors I get.

  1. parentNode
Uncaught (in promise) TypeError: Cannot read properties of null (reading 'parentNode')
    at parentNode (chunk-BVQHDTV7.js:9157:30)
    at ReactiveEffect.componentUpdateFn [as fn] (chunk-BVQHDTV7.js:7175:11)
    at ReactiveEffect.run (chunk-BVQHDTV7.js:423:19)
    at instance.update (chunk-BVQHDTV7.js:7212:52)
    at updateComponent (chunk-BVQHDTV7.js:7039:18)
    at processComponent (chunk-BVQHDTV7.js:6974:7)
    at patch (chunk-BVQHDTV7.js:6436:11)
    at patchSuspense (chunk-BVQHDTV7.js:2562:7)
    at Object.process (chunk-BVQHDTV7.js:2481:7)
    at patch (chunk-BVQHDTV7.js:6461:16)
  1. subTree
Uncaught (in promise) TypeError: Cannot read properties of null (reading 'subTree')
    at move (chunk-BVQHDTV7.js:7520:28)
    at move (chunk-BVQHDTV7.js:7520:7)
    at Object.resolve (chunk-BVQHDTV7.js:2789:11)
    at chunk-BVQHDTV7.js:2912:20

Unlike everyone facing the issue, I don’t have any transitions enabled nor am I using any layouts. I have my <NuxtPage /> wrapped in a <div> and ssr is set to false in my Nuxt config. I am however using useAsyncData which doesn’t seem to be a problem with other projects running on the same stack.

I’m still exploring the vue issue but so far seems unrelated, will open a separate issue when I can make a reproduction. If anyone has the same issue and is facing it, let me know how you solved it if you did 😓

This issue still exists 3.6.5. If setting a different layout per page, this happens. followed the official doc. The layout “feature” seems completly broken.

I just noticed that the fix does not work when using navigateTo (for a 302 redirect to a different route with the same layout) inside a component

@frasza thank you very much

Can anyone provide a few more minimal reproductions, if you still have the error with npm:nuxt3@pr-21450? Thanks

I am trying to make sense of it. In our case, this happens with the same layout, with no switching between layouts at all. We can also force-replicate it with the same amount of clicks.

Will try to create a repo but need to figure create a simple version.

I had hope but we still get this error randomly after about 4 NuxtLink clicks:

[Vue warn]: Unhandled error during execution of scheduler flush. This is likely a Vue internals bug. Please open an issue at https://new-issue.vuejs.org/?repo=vuejs/core 
  at <RouterView name=undefined route=undefined > 
  at <NuxtPage> 
  at <Default > 
  at <LayoutLoader key="default" name="default" hasTransition=false > 
  at <NuxtLayout> 
  at <App key=3 > 
  at <NuxtRoot> [deps:1449:13](http://localhost:5001/_nuxt/node_modules/.cache/vite/client/deps/)
Uncaught (in promise) TypeError: node is null
    NuxtJS 6

But it does seem like @antfu is on the right track.

@jbreuil @mdanilowicz @niklaswolf, try using shallowRef instead of ref in the script section of your component/page. I tested it with your stackblitz and it looks like a possible solution, or at least a workaround.

For example:

const slides = ref<HTMLElement[] | null>(null)
// becomes:
const slides = shallowRef<HTMLElement[] | null>(null)

Another workaround solution (which I didn’t like too much for myself, but wanted to mention anyway) is to unset the variable before the component unmounts:

let slides = ref<HTMLElement[] | null>(null)
onBeforeUnmount(() => {
  slides = undefined
})

Hopefully this helps! 🙏

Vue 3 has no way to automatically detect if SSR is used — so nuxt, gridsome, and other SSR frameworks must manually set the ssr option to true in order to properly render the application. https://vuetifyjs.com/en/getting-started/installation/

const vuetify = createVuetify({ ssr: true, })

My current solution (short term) was to turn off the server side rendering.

@danielroe I slightly adjusted the reproduction so that the component is included in one of the layouts directly: https://stackblitz.com/edit/github-ab3jsk?file=components%2FMyComponent.vue

@danielroe Reproduction link of one case I was able to spot, I am pessimistic that this case is the only one or the one experienced by people in this thread but it may help in some way : reproduction

In this reproduction, the error is triggered when like described in this issue the layout is changed on routing. The error is caused by the use of a ref element in the component. The ref is on a v-for following the documentation syntax and typing

The big problematic is that when this error appear in a real project since there is no clue on the cause you have to delete parts of code until you spot what is the root cause.

I can reproduce it the exact same way in my app: a component in one layout contains a Template-Ref, if I remove this component (which is obv. not a real world option), it works fine

Very interesting. As @tidan-16 suggested downgrading Nuxt from 3.5.2 -> 3.4.3 did in fact resolve the issue for us. We did not change anything else, no added divs etc.

That said here is my dev debug results:

Nuxt 3.4.3 This does resolve the issue when clicking between routes using the <RouterLink>

[…slug].vue

<template>
  <div>
    <PageList :content="content" v-if="pageList" />
    <PageHolder
      :content="content"
      v-else-if="(!pageList && content?.body) || content?.title"
    />
    <div v-else>
      <NoResultAnim />
    </div>
  </div>
</template>

app.vue

<template>
  <NuxtLayout>
    <NuxtLoadingIndicator />
    <NuxtPage />
  </NuxtLayout>
</template>

Notes: if you add definePageMeta with keepalive: true then you can replicate the issue:

<script lang="ts" setup>
definePageMeta({
  keepalive: true,
})
</script>

Adding pageTransition: { name: 'default', mode: 'out-in' }, can break it as well.

error [Vue warn]: Unhandled error during execution of scheduler flush. This is likely a Vue internals bug. [Error] Unhandled Promise Rejection: TypeError: null is not an object (evaluating 'node.parentNode')

partial solution If you add the following to app.vue the issue is resolved: <NuxtPage :key="$route.fullPath" /> but breaks pagemeta: keepalive: true


Nuxt 3.5.2

All of the above is the same except without even using definePageMeta you will still get the same error:

[Vue warn]: Unhandled error during execution of scheduler flush. This is likely a Vue internals bug. [Error] Unhandled Promise Rejection: TypeError: null is not an object (evaluating 'node.parentNode')

partial solution If you add the following to app.vue the issue is resolved: <NuxtPage :key="$route.fullPath" /> but breaks pagemeta: keepalive: true


Best solution for now is Nuxt 3.4.3 without transition or definemeta…

I hope this helps and if more information is needed let me know.

@danielroe Reproduction link of one case I was able to spot, I am pessimistic that this case is the only one or the one experienced by people in this thread but it may help in some way : reproduction

In this reproduction, the error is triggered when like described in this issue the layout is changed on routing. The error is caused by the use of a ref element in the component. The ref is on a v-for following the documentation syntax and typing

The big problematic is that when this error appear in a real project since there is no clue on the cause you have to delete parts of code until you spot what is the root cause.

Please someone tell me, how is this framework production ready when something as simple as a route change has such a bug.

It surely needs to be fix asap, but does not mean this framework is not production ready

Do you prefer building apps where users cannot change their route on page refresh?

@danielroe sure I’ll try to reproduce on a new instance !

Same issue here using navigateTo https://stackblitz.com/edit/nuxt-starter-wfjgaf?file=pages/index.vue

Exactly the same issue, Were you able to fix this?

OK, I found the problem

It was a missing defineAsyncComponent(...) in one of the components. if you are using ()=> import() as a async component, the whole tree will broke with this error message.

I see the same problem also when the NuxtPage is navigating from page to page

//the function with error 
const isAsyncWrapper = e=>!!e.type.__asyncLoader;
//e is a   empty Vue object
JSON.stringify(e) 
'{"__v_isVNode":true,"__v_skip":true}'

But not only. I can see the same error in other defuneAsyncComponent(...) components. the function isAsyncWrapper is called with empty e.type, so the check for __asyncLoader is failed.

@Teplophizik Хорооош =) For me it was not so critical so I easily switched from pages to components. But this bug can be very annoying in deeply nested layouts…

The only fix for me was to disable transitions. Took me a while figuring out how this is done with TSX.

app.vue

<script lang="tsx" setup></script>
<template>
  <div>
    <NuxtPage :transition="false" />
  </div>
</template>

defineMetaPage cannot be used inside TSX files since it’s compiled away. https://v3.nuxtjs.org/api/utils/define-page-meta/#definepagemeta. This is off topic, but does anybody know how to use this API with JSX/TSX files?

Got the same error. Fixed by adding wrapper tag <v-no-ssr> around <v-snackbar>:

But it took a long time to find this place

 <v-no-ssr>
      <v-snackbar v-model="snackbar.show" top multi-line :timeout="snackbar.timeout" :color="snackbar.color">
        {{ snackbar.text }}
        <template #actions>
          <v-btn color="secondary" @click="snackbar.show = false">
            Close
          </v-btn>
        </template>
      </v-snackbar>
    </v-no-ssr>

Thanks, it work. Same problem with component <v-menu>

I’ve been pulling my hair out trying to figure out what was throwing this error and in my case I was able to get it resolved by removing any top level await functions in my vue components.

@rvmourik is on the right track, I went ahead and recreated the <NuxtPage /> component, when I remove the <Transition /> before the <NuxtLayout /> the error does not pop up, but the page:start and the page:finish are still not firing

I did the exact same thing to work around the error, it might be related to the combination of dynamic routes and nested pages.