Ensure errors during component creation do not cause secondary errors during DOM cleanup #1073
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently we don't do any cleanup in the event of an error occuring during the actual execution of the VM. This can leave the VM in a bad state, in particular the element builder, since it doesn't actually finalize block nodes until _after_ the entire block has executed. This means that if an error occurs during the execution of a block, the VM will never properly initialize those blocks, and their first and last nodes will be `null`. While we don't currently support recovering from this type of an error, we do need to be able to cleanup the application after one, specifically for tests. Previously, this worked no matter what because of the Application Wrapper optional feature - there was always a root `div` element that we could clear, so there was always a first and last node for us to track. With the feature disabled, we started seeing failures such as [this issue within user tests](emberjs/ember-test-helpers#768 (comment)). This PR refactors VM updates, specifically, to allow them to properly clean up the element builder on failures. It now closes all remaining open blocks, finalizing them to ensure they have nodes. This only works for VM updates because the initial append is an _iterator_, which the user controls execution of. We'll need to have a different strategy for this API, but it shouldn't be a regression at the moment because any failures during the iteration will result in a completely broken app from the get-go. There is no result, and no accompanying `destroy` function, so existing tests and apps cannot be affected by failures during append.
pzuraq
commented
Apr 16, 2020
| @@ -90,7 +90,7 @@ export interface ElementBuilder extends Cursor, DOMStack, TreeOperations { | |||
| constructing: Option<SimpleElement>; | |||
| element: SimpleElement; | |||
|
|
|||
| block(): LiveBlock; | |||
pzuraq
commented
Apr 16, 2020
| @@ -165,10 +164,6 @@ export default abstract class VM<C extends JitOrAotBlock> implements PublicVM, I | |||
| return this[INNER_VM].stack as EvaluationStack; | |||
| } | |||
|
|
|||
| currentBlock(): LiveBlock { | |||
rwjblue
approved these changes
Apr 16, 2020
rwjblue
approved these changes
Apr 16, 2020
rwjblue
changed the title
rwjblue
changed the title
rwjblue
added a commit
to emberjs/ember.js
that referenced
this pull request
Apr 16, 2020
…g cleanup). Changelog from the release: * `@glimmer/integration-tests`, `@glimmer/interfaces`, `@glimmer/runtime` * [#1073](glimmerjs/glimmer-vm#1073) Ensure errors during component creation do not cause secondary errors during DOM cleanup ([@pzuraq](https://github.com/pzuraq)) - Chris Garrett ([@pzuraq](https://github.com/pzuraq))
rwjblue
added a commit
to emberjs/ember.js
that referenced
this pull request
Apr 16, 2020
Backport of the changes in [glimmerjs/glimmer-vm#1073](glimmerjs/glimmer-vm#1073) to 0.38.5-alpha branch (used by ember-source@3.16).
rwjblue
added a commit
to emberjs/ember.js
that referenced
this pull request
Apr 23, 2020
…g cleanup). Changelog from the release: * `@glimmer/integration-tests`, `@glimmer/interfaces`, `@glimmer/runtime` * [#1073](glimmerjs/glimmer-vm#1073) Ensure errors during component creation do not cause secondary errors during DOM cleanup ([@pzuraq](https://github.com/pzuraq)) - Chris Garrett ([@pzuraq](https://github.com/pzuraq)) (cherry picked from commit cf4a4bc)
kiwiupover
added a commit
to kiwiupover/ember-render-modifiers
that referenced
this pull request
Aug 3, 2021
This PR fixed an issue that causes and error to be thrown twice for ember versions <= 3.15 glimmerjs/glimmer-vm#1073
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently we don't do any cleanup in the event of an error occuring
during the actual execution of the VM. This can leave the VM in a bad
state, in particular the element builder, since it doesn't actually
finalize block nodes until after the entire block has executed. This
means that if an error occurs during the execution of a block, the
VM will never properly initialize those blocks, and their first and last
nodes will be
null.While we don't currently support recovering from this type of an error,
we do need to be able to cleanup the application after one, specifically
for tests. Previously, this worked no matter what because of the
Application Wrapper optional feature - there was always a root
divelement that we could clear, so there was always a first and last node
for us to track. With the feature disabled, we started seeing failures
such as this issue within user tests.
This PR refactors VM updates, specifically, to allow them to properly
clean up the element builder on failures. It now closes all remaining
open blocks, finalizing them to ensure they have nodes.
This only works for VM updates because the initial append is an
iterator, which the user controls execution of. We'll need to have a
different strategy for this API, but it shouldn't be a regression at the
moment because any failures during the iteration will result in a
completely broken app from the get-go. There is no result, and no
accompanying
destroyfunction, so existing tests and apps cannot beaffected by failures during append.