Skip to content
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

[WIP BUGFIX] Prevent failed relationship fetches from causing infinite re-render and re-fetch #5492

Merged
merged 3 commits into from Jun 21, 2018

Conversation

runspired
Copy link
Contributor

Resolves #5479

Fix here is only for legacy build, I still need to port changes to the record-data build.
This will also need ported to 3.2 prior to release; however, doing so is likely non-trivial as a cherry-pick, so I will open a PR specific to 3.2 once this PR is complete.

cc @HeroicEric @fivetanley @rwjblue

@rwjblue
Copy link
Member

rwjblue commented Jun 19, 2018

How is this looking? I’d really like to get this landed and release 3.2..

@runspired
Copy link
Contributor Author

@rwjblue need to add the fix you suggested for LTS, otherwise I think it's ready

.eslintrc.js Outdated
@@ -1,5 +1,6 @@
module.exports = {
root: true,
parser: 'babel-eslint',
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did not add this manually, unsure how this came in. @rwjblue any ideas?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rebase issue maybe? I don’t think we should need a special parser should be able to remove...

return this._handleCompletedFind();
},
e => {
return this._handleCompletedFind(e);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

splitting this into two methods might be much nicer

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

if (inverseInternalModel) {
if (shouldForceReload && inverseInternalModel.hasRecord) {
// reload record, if it is already loaded
promise = inverseInternalModel.getRecord().reload();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we have a link, shouldn't we go fetch the link instead of reloading the record?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a code comment, but we branch prior to that.

return this.members.list;
}

get hasRelatedResources() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please write a comment describing the intended behavior of this method

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to be maybe equivalent to the hasLoaded property? If i'm reading this correctly, it should return true if you have an empty array, in which case the naming is pretty misleading

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changed to allInverseRecordsAreLoaded


get hasRelatedResources() {
// check currentState for unloaded records
let hasEmptyRecords = this.currentState.reduce((hasEmptyModel, i) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would this be cleaner to write as a find/filter?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unsure, I find I have to similarly pause and reason for any of the three approaches. Happy to embrace another pattern if there's one you prefer,

}
}

this.setRelationshipIsStale(true);
this.setHasFailedLoadAttempt(false);
this.setShouldForceReload(true);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whats the thinking behind setting this on the object/interaction with the scheduleFetchMany?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unsure what you mean? this is for a forced reload..

//TODO(Igor) sync server here, once our syncing is not stupid
let manyArray = this.manyArray;

if (this.isAsync) {
if (this.shouldMakeRequest()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❤️

=> we get a new link for the relationship
*/
this.relationshipIsStale = !internalModel.isNew();
this.relationshipIsStale = !this.isNew;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a comment as to what the difference between forcing a reload and a stale relationship is

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

return false;
}

// Always make a request when forced
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❤️

@@ -1871,7 +1871,7 @@ Store = Service.extend({
snapshot: snapshot,
resolver: resolver,
});
emberRun.once(this, this.flushPendingSave);
emberRun.scheduleOnce('actions', this, this.flushPendingSave);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's this about

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that we have setup waiters for our backburner instance, we no longer need the autorun assertion. This allows folks (including ourselves) to use async await without wrapping everything in run loops.

@@ -0,0 +1,653 @@
import { module } from 'qunit';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Many ❤️

@runspired runspired force-pushed the has-many-acceptance-tests branch 2 times, most recently from 473abc4 to f311140 Compare June 20, 2018 20:39
skip record-data failures for now
@runspired runspired merged commit 4f53ebd into master Jun 21, 2018
@runspired runspired deleted the has-many-acceptance-tests branch June 21, 2018 04:46
runspired added a commit that referenced this pull request Jun 21, 2018
runspired added a commit that referenced this pull request Jun 21, 2018
…5499)

* [BUGFIX beta] ports fix for infinite-relationship-retry from #5492

DDOS is bad

* bump node version
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants