Version

3.0.6

Reproduction link

https://codesandbox.io/s/invalid-vnode-breaks-conditionals-39zqo

Steps to reproduce

In a conditional group, render an invalid vnode, then change the condition so that it'll render a valid vnode.

What is expected?

It should render the valid vnodes after having rendered an invalid vnode.

What is actually happening?

The conditional group breaks with Cannot read property 'parentNode' of undefined errors.

The runtime raises the [Vue warn]: Unhandled error during execution of scheduler flush. This is likely a Vue internals bug. warning.

This issue came up when a user tried to define an async component as a function returning the result of calling defineAsyncComponent.

{
  component: () => defineAsyncComponent(() => import('./Foo.vue'))
}

This seemingly makes the runtime think it's a functional component, which returns the resulting object of defineAsyncComponent(...), and that is of course not a valid vnode.

It should render the valid vnodes after having rendered an invalid vnode.

Not sure how to interpret that.

What do you expect Vue to render/do when it receives a "functional component" that really isn't one? just render nothing, and essentially silently fail? Throw a warning? an error?

I think we can improve the error message here, but it should throw an error when a functional component doesn't return a vnode like it's supposed to, shouldn't it?

What do you expect Vue to render/do when it receives a "functional component" that really isn't one? just render nothing, and essentially silently fail? Throw a warning? an error?

Rendering nothing and throwing a warning is the current behaviour. This issue is about what happens after.

It's not intuitive to me that something that only raises a warning should then make the component break. As there's no error after rendering the invalid vnodes was attempted, I think it's reasonable to think that it should continue without error. Especially when the proceeding actions are completely valid.

It may make sense in this scenario, but may cause a break later in other scenarios, which then would have to be traced back to the warning.

If you try to render something that is not a valid vnode / component / null, you wrote code that is fundamentally wrong and you probably shouldn't be able to ignore a warning and proceed with your development - maybe ending up commiting code that breaks the app. You should stop, find the fundamental error in your code and fix it before moving on.

OTOH, I assume you are thinking more in the direction of an app that can recover as best as possible from such an error?

Cosed, like @LinusBorg said, don't use lies to verify lies, so don't use the wrong usage to verify the unexpected. Warnings don’t mean you don’t need to pay attention, you should fix it.