Data: findRecord with { reload: true } does not reload cached record

[irnc]

This regression was introduced in https://github.com/emberjs/data/commit/0ac6ba4f331eecf3a3ddddccd76808520fbc7a45 for 2.0 and in https://github.com/emberjs/data/commit/75bec5ec1b1b842ee87eb4cb2fb0b6dbe1b93d85 for 1.13 bracnhes.

In current code, _findRecord function checks reload option and schedules fetch if it is true, but this function is never called if record is already in cache.

You can see that Store#findRecord would never reach the call to _findRecord for cached records and would return result of _findByInternalModel which does not check for reload option.

[bmac]

Oops. How did I miss that? Thanks for reporting this issue @irnc.

[visoft]

Is there a fix for this? I discovered the same bug that @irnc found. I'm on the 1.13.13 release of Ember Data.

[graup]

I just ran into this problem and would be willing to contribute a fix. But I wonder where that should go? Just add a check for && !options.reload in https://github.com/emberjs/data/blob/75bec5ec1b1b842ee87eb4cb2fb0b6dbe1b93d85/packages/ember-data/lib/system/store.js#L624 ?

[visoft]

@graup - I tried that fix locally. It does go through and call scheduleFetch, but it seems to still grab it from the cache. At least in my testing, it doesn't go out and call the server again.

[tuomole]

We're currently facing this problem, as we need to reload a cached record before editing it. As a dirty workaround we do model.reload() in route's afterModel hook, which causes 2 requests to the server when there's no record in the cache already.

Any updates about the proposed fix?

Ember 1.13.7
Ember Data 1.13.8

[DLiblik]

We implemented the same workaround (calling reload), but get a double-tap to the server as well... hoping somebody has nothing better to do this weekend ;)

[pangratz]

I cannot reproduce using ember-data v1.13.15: https://ember-twiddle.com/5e7aad8a008b29029d06?numColumns=1&openFiles=application.route.js

Someone still hit this bug?

[vvainio]

I bumped into this issue on the aforementioned ember-data v1.13.15. Resorting to calling model.reload() until this is resolved.

[pangratz]

@vvainio can you create an ember-twiddle demonstrating your issue? I had trouble reproducing...

[vvainio]

@pangratz, upon further inspection I can conclude there is no bug in Ember-Data. Our use-case is quite complex, but the root cause is that the records are stored using uuid as the primary key, whereas human readable identifiers are used for querying the API. This causes the hasRecordForId method to always return false even if the record is loaded as the identifiers do not match.

[pangratz]

@irnc @visoft @tuomole @DLiblik can somebody confirm that this is still an issue?

[DLiblik]

@pangratz we upgraded to 1.13.15 and are not seeing the issue. I don't have access to a 1.13.8 environment to re-run the test. So at this time I am considering this item closed. I can say that we tested it pretty hard on 1.13.8 and it was definitely an issue there, so somewhere between ..8 and ..15 somebody gave this a hug.

[bmac]

Closing based on @DLiblik comment. Let me know if this is still an issue and I will reopen.

[mattbearman]

I'm still seeing this issue on 2.4.3, doing the following doesn't cause the model to fetch from the API if it's already in the cache:

model(params) {
  return this.store.findRecord('website', params.website_id, { reload: true });
}

At the moment I'm just using the afterModel hook to force a reload, but it would be good to get the reload flag working again.

[davidlormor]

Just to add context to @mattbearman's comment - I'm running on canary using JSONAPI adapters/serializers and experiencing the same issue.

[pangratz]

@davidlormor @mattbearman I cannot reproduce using canary ember-data, see this ember-twiddle. Can you update the twiddle so it demonstrates the issue you're having? That would be really helpful!

[davidlormor]

@pangratz it seems I can't reproduce on the twiddle...it appears that it may have something to do with the way Ember CLI Mirage is mocking requests. Will do a bit of research today and follow up. @mattbearman - are you using Ember CLI Mirage (or something similar) too? Or are you experiencing the issue w/ actual XHR requests?

[pangratz]

@davidlormor thanks for the heads up. If this is something mirage related, you can also try to reproduce in canary ember-twiddle, which supports addons now (you could take this as a starting point). I am just saying, don't feel obliged to reproduce it in ember-twiddle.

[davidlormor]

Rookie mistake here - I was passing in the model rather than the ID, which was why the reload option wasn't firing. @mattbearman - could this be your issue as well? Seems like this could be a potential stumbling block (especially for new users). I'll open a new issue to continue discussion around possible API clarifications. Thanks for your help @pangratz!

[DLiblik]

@davidlormor can you confirm then that using the ID does work as advertised in your environment?

[davidlormor]

@DLiblik yes, it works as expected when the ID is passed in.

[pangratz]

I was passing in the model rather than the ID, which was why the reload option wasn't firing.

@davidlormor I am curious on how your method call looked in that situation. Something like store.findRecord('user', admin)? I'm asking because maybe we can improve this situation so it is caught by an assertion...

[davidlormor]

@pangratz - I was calling the method as expected: store.findRecord('client', params.id, {reload: true}). As I mentioned, there was nothing wrong with the method call, rather, the fact that the method was located in the route's model hook was causing the method to never be fired. I've opened an issue on the RFCs repo to discuss this further. I think a more declarative syntax between link-to and the model hook with good docs and sane defaults would help out here. Basically, something to make the developer aware that you passed an object, not an id, into a link-to helper, so your model hook will not fire.

The imperative nature of the whole API seems to be a possible source for very subtle bugs that are hard to track down.

[pangratz]

I was passing in the model rather than the ID

@davidlormor ah, now I see what you meant there. Thanks for the clarification.

[mattbearman]

I'm passing in the model id, direct from url params and still seeing this issue. I am also using Ember CLI Mirage (0.1.11), but I'm seeing this issue when connecting to an actual database, so I don't think Mirage is the cause.

I'm also using Active Model Adapter 2.1.1, could that be causing this?

[pangratz]

@mattbearman which version of ember-data are you using? I cannot reproduce with 2.5.2, see this ember-twiddle.

[mattbearman]

I'm currently on 2.4.3, I'll try upgrading and see if that does anything

[mattbearman]

Turns out I was passing the model rather than the id as well, managed to mis-read my own code 😖 passing the id fixed it.

[meliborn]

Got the same issue, but my ID looks like '2.0'
return this.store.findRecord('company', params.company_id, {include: 'accounts', reload: true});

DEBUG: -------------------------------
ember.debug.js:6440DEBUG: Ember : 2.5.1
ember.debug.js:6440DEBUG: Ember Data : 2.10.0
ember.debug.js:6440DEBUG: jQuery : 2.2.4
ember.debug.js:6440DEBUG: Ember Simple Auth : 1.1.0
ember.debug.js:6440DEBUG: -------------------------------

[pangratz]

@meliborn can you update this ember-twiddle to demonstrate the issue you're having?

[samharnack]

@pangratz Here's the behavior I am experiencing. I'm not entirely sure its related to this issue. My scenario is using SSE to trigger the reload of the record in the background.

It appears that { reload: true } works the first time its called, but not the subsequent times. Would it be related to this?

Hopefully this helps.

[FenzaFenz]

I have the same issue. Ember data 2.11.0. The app makes GET request, but doesn't seem to update the store.

[bmac]

@FenzaFenz would you be able to recreate the issue in an ember twiddle or separate repo?

@samharnack It looks like in your example the record returned from the /people/2.0 request has an id of 1. When I updated the response to use "2.0" as the id everything appears to work as expected. https://ember-twiddle.com/b34088006bd4939a2c07e94ecc36b61c?numColumns=2&openFiles=routes.application.js%2Ctemplates.application.hbs

[fpalluel]

Hi, I just experienced the same issue as @samharnack .
I load my-model in the model hook of a route.
Later, in a component, I do a findRecord('my-model', id, {reload: true, include: 'sub-model'}.
The GET request is triggered, but the include does not appear in the url, as if the include option is ignored.
When I do the same findRecord, but with an id of a model which as not been previously loaded, the include works as expected.

All of this, using ED 2.13.1

[Syzygy24]

Can we re-open this @bmac ?
I am also having the Same issue as @samharnack with Ember data 2.11.3.

in my route I have a findRecord('model', id, {reload: true}) and it doesn't make a call to the server the second time the route is loaded.

[kdomagal]

make sure it's not your browser caching the request

[Syzygy24]

I have chrome set to disable its cache while the devtools tab is open. So probably not the browser. I'm not seeing Ember make the request.

[kdomagal]

I added "Cache-Control: no-cache" header in my requests and that solved it. Not ideal but for know it's some kind of workaround

[fran-worley]

@Syzygy24 seeing this in Ember Data 2.15.0-beta.2 too. No request is made when providing the reload option:

import Ember from 'ember';

export default Ember.Route.extend({
  model: function(params) {
    return this.store.findRecord('myModel', params.model_id, {reload: true, include: 'some-model-to-include'});
  }
});

[fran-worley]

@bmac I've done some digging and it only seems to ignore my reload option if other options are passed in:

// this forces a new request
this.store.findRecord('myModel', params.model_id, {reload: true});

// this doesn't
this.store.findRecord('myModel', params.model_id, {reload: true, include: 'some-model-to-include'});

// I tried this incase I'd read the docs wrong and this doesn't work either:
this.store.findRecord('myModel', params.model_id, {reload: true}, {include: 'some-model-to-include'});

Update: It actually looks like the above is not the case, my model hook wasn't always being called! this article cleared this up: https://emberigniter.com/force-store-reload-data-api-backend/

[joehany]

So the trick is to let links to that route pass in the model id not the model directly!
Thanks @fran-worley

[kdomagal]

In that case the documentation should be updated then.

[pangratz]

This is mentioned in the guides https://guides.emberjs.com/v2.15.0/routing/specifying-a-routes-model/#toc_dynamic-models:

Note: A route with a dynamic segment will always have its model hook called when it is entered via the URL. If the route is entered through a transition (e.g. when using the link-to Handlebars helper), and a model context is provided (second argument to link-to), then the hook is not executed. If an identifier (such as an id or slug) is provided instead then the model hook will be executed.

Any ideas on how and where this should be improved?

[kdomagal]

@pangratz it should be mentioned somewhere in ember-data docs around that "reload" option

[pangratz]

As far as I understood all the mentioned issues within this thread, the problem is not within ember data and the { reload: true } option, but that the model hook itself is not called on the route, when you pass the {{link-to}} helper a model...

[thilinadinith]

error in ember data :

      this.controllerFor('people/profile').store.findRecord( 'profile', id, {reload:true}).then( response => {

        this.controllerFor( 'people/profile' ).set( 'user',response);
        this.controllerFor( 'people/edit' ).set( 'person',response );

});

expected : flush the dirty record of the id which is findRecord and update with new backend data.
but it doesn't update dirty record in model.

Ember Data 2.18.0