fix(core): error in TestBed if module is reset mid-compilation in ViewEngine #42669
Conversation
jessicajaniuk
approved these changes
Jun 28, 2021
LGTM
This comment was marked as off-topic.
This comment was marked as off-topic.
alxhub
approved these changes
Jun 29, 2021
IgorMinar
approved these changes
Jun 30, 2021
Whoa! What a temporal bug. Thanks for fixing this. I left a suggestion to make the test more robust.
…wEngine When `TestBed.compileComponents` is called under ViewEngine, we kick off a compilation and return a promise that resolves once the compilation is done. In most cases the consumer doesn't _have_ to await the returned promise, unless their components have external resources. The problem is that the test could be over by the time the promise has resolved, in which case we still cache the factory of the test module. This becomes a problem if another compilation is triggered right afterwards, because it'll see that we still have a `_moduleFactory` and it won't recreate the factory. These changes resolve the issue by saving a reference to the module type that is being compiled and checking against it when the promise resolves. Note that while this problem was discovered while trying to roll out the new test module teardown behavior in the Components repo (angular/components#23070), it has been there for a long time. The new test behavior made it more apparent.
jessicajaniuk
added a commit
that referenced
this issue
Jun 30, 2021
…wEngine (#42669) When `TestBed.compileComponents` is called under ViewEngine, we kick off a compilation and return a promise that resolves once the compilation is done. In most cases the consumer doesn't _have_ to await the returned promise, unless their components have external resources. The problem is that the test could be over by the time the promise has resolved, in which case we still cache the factory of the test module. This becomes a problem if another compilation is triggered right afterwards, because it'll see that we still have a `_moduleFactory` and it won't recreate the factory. These changes resolve the issue by saving a reference to the module type that is being compiled and checking against it when the promise resolves. Note that while this problem was discovered while trying to roll out the new test module teardown behavior in the Components repo (angular/components#23070), it has been there for a long time. The new test behavior made it more apparent. PR Close #42669
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
When
TestBed.compileComponentsis called under ViewEngine, we kick off a compilation and return a promise that resolves once the compilation is done. In most cases the consumer doesn't have to await the returned promise, unless their components have external resources.The problem is that the test could be over by the time the promise has resolved, in which case we still cache the factory of the test module. This becomes a problem if another compilation is triggered right afterwards, because it'll see that we still have a
_moduleFactoryand it won't recreate the factory.These changes resolve the issue by saving a reference to the module type that is being compiled and checking against it when the promise resolves.
Note that even though this problem was discovered while trying to roll out the new test module teardown behavior in the Components repo (angular/components#23070), it has been there for a long time. The new test behavior made it more apparent.
The text was updated successfully, but these errors were encountered: