[bugfix] Prevents the recursive redefinition of root chains #16857
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
This fix prevents an edge case where recursive call to `writableChains` causes the root `_chains` ChainNode on a meta to be overwritten, resulting in a chains node that does not match up with the `watching` state of the meta. This can occur when: 1. A computed property has been setup on a class, which lazily delays finalizing chains. 2. An observer is then added to the class, which eagerly forces its dependencies to setup their chains. In the case observed, it was only triggered because there were some number of intermediate aliases between the `computed` and the `observer`. Aliases are not volatile, but they also don't use the computed cache for values so they cannot rely on `getCachedValueFor` when setting up chains. This results in eager fetching of computed values, which leads to the nested recursive call. This PR solves the problem by ensuring that the root chain node is set on the meta before we attempt to add any values to it (e.g. with `copy`). The copy method has been renamed to `copyTo` to indicate that it is not actually creating or returning a copy (open to suggestions for a better name).
pzuraq
force-pushed
the
bugfix/prevent-redefinition-of-root-chains
branch
from
9c31649
to
b4026e0
Compare
rwjblue
approved these changes
Aug 2, 2018
There was a problem hiding this comment.
Seems good to me, though I couldn’t imagine being able to figure this out on my own 😜
Adding @krisselden for additional review...
krisselden
reviewed
Aug 6, 2018
| assert.expect(0); | ||
| function didChange() {} | ||
|
|
||
| let obj = { |
There was a problem hiding this comment.
I'd prefer using class syntax, and defining the CPs on prototype then calling finish chains in the constructor
There was a problem hiding this comment.
Mind sending a follow up PR for that?
krisselden
approved these changes
Aug 6, 2018
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.
This fix prevents an edge case where recursive call to
writableChainscauses the root
_chainsChainNode on a meta to be overwritten,resulting in a chains node that does not match up with the
watchingstate of the meta.
This can occur when:
finalizing chains.
dependencies to setup their chains.
In the case observed, it was only triggered because there were some
number of intermediate aliases between the
computedand theobserver. Aliases are not volatile, but they also don't use thecomputed cache for values so they cannot rely on
getCachedValueForwhen setting up chains. This results in eager fetching of computed
values, which leads to the nested recursive call.
This PR solves the problem by ensuring that the root chain node is set
on the meta before we attempt to add any values to it (e.g. with
copy). The copy method has been renamed tocopyToto indicate thatit is not actually creating or returning a copy (open to suggestions
for a better name).