-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix and tests for unloadRecord => findRecord issue #5011
Conversation
store.unloadRecord(record); | ||
assert.equal(record.isDestroying, true, 'the record is destroying'); | ||
assert.equal(internalModel.currentState.stateName, 'root.empty', 'We are unloaded after unloadRecord'); | ||
store.findRecord('person', '1'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this should likely cancel the above unloadRecords
's _checkForOrphanedInternalModels
and unset _isDematerializing
, so it can be back in a pristine place, ready for a findRecord
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
8059897
to
cd5e254
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the test need to be test observable behavior over implementation details. Especially for the resurrection cases. Lots of things can go side-ways there, especially as we refactor codez.
assert.notEqual(timer, null, 'We scheduled destroy'); | ||
store.unloadRecord(record); | ||
let newTimer = internalModel._scheduledDestroy; | ||
assert.equal(newTimer, timer, 'We scheduled destroy only once'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there a way for us to test the observable behavior of this rather then the implementation? Specifically, i suspect this will cause issues \w resurrection, and it should be possible to test that directly.
|
||
run(function() { | ||
store.unloadRecord(record); | ||
let timer = internalModel._scheduledDestroy; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should aim to test observable behavior. This seems to tied to implementation details.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about two calls to scheduleDestroy
followed by a cancelDestroy
and testing that isDestroyed
is false?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yup, something like that sounds good. I just want to maximize test value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hjdivad would love your 👀 on this as well.
if (this._isDematerializing === true) { | ||
this._isDematerializing = false; | ||
run.cancel(this._scheduledDestroy); | ||
this._scheduledDestroy = null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason to not put this outside the above if
statement? I suspect always nulling this one here, will prevent us from accidentally not nulling it out sometimes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. The intent was to avoid unnecessary work if we weren't in a state that needed to be cleaned up, but this isn't the correct check for that. Moved to just always resetting all three things.
…dRecord, adds test coverage
63371a9
to
d0b64ee
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@bmac we likely need to bugfix release this guy. |
The underlying issue was that the internalModel was not cleaning up it's
destroy
call and flags when being rematerialized immediately.