-
-
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
Catching errors from backgroundReload #3809
Comments
Hi @nicolas-dular. I agree that we should add some way to expose errors with background loaded record arrays. Retuning the promiseArray(_findAll(adapter, this, typeClass, sinceToken, options)); would cause the |
What I do currently as a workaround is that I override We have avoided most occurrences by making a smarter Edit: I would be happy to share my "smart" solution with you if you want to 😄 |
@philipp-spiess I think something like I think the long term solution is likely to involve implementing a general purpose event system for the store so users can react to this error and other events. |
closing in-favor of RFC. |
Are there any updates on this yet? Is there a officially supported solution? I am facing the same issue now and I would assume this scenario is not very uncommon. |
@stefanpenner Why did you close this? I believe, the issue should stay open until an implementation PR of the RFC (not the RFC PR) is merged into master. But currently the RFC does not even exist. The problem, on the other hand, is very real. The workaround of overriding private API and relying on global events does not feel right either. Please reopen! 🙇♂️ |
@lolmaus you should be able to explore solutions using the REQUEST_SERVICE feature flag. This is obviously experimental API (hence the feature flag) so feedback on ergonomics & utility are of course welcome. This use case seems squarely in the realm of what the request service ought to enable: if it's a pain to handle this that to me is a clear sign we need to iterate on the request service API. cc @igorT |
I’ve hit issue of catching background fetch promises as well. I’ll probably turn off background reloading for “quick fix”. |
Assigned to @igorT to validate this works with REQUEST_SERVICE |
I have a few thoughts on how to improve this with RFC emberjs/rfcs#860 Since the RFC gives control over catching and handling the error to the request-manager, end users can choose to swallow the error. This allows us to consider two options:
I'm going to leave this feedback on the RFC as something to add to it, and close this in favor. |
Let's says we have a
UsersIndexRoute
where we load all users.When we load the page for the first time (hard reload) and get a
HTTP 500 error
back we get this error in theApplicationRoute
'serror()
and can render an error page and everything is fine.But: Let's says we already loaded the Ember App but only loaded a subset of all users, go to the
/users
page and callfindAll()
again. Ember immediately gives back the subset of users we already loaded in the store and fetches all the other users in a background request.Now in our case we get a
HTTP 500 error
back in the backgroundReload, but it seems like https://github.com/emberjs/data/blob/master/packages/ember-data/lib/system/store.js#L1027 doesn't return the promise array back and we can't catch the error infindAll()
anymore, or receiving any error in theApplicationRoute
'serror()
.My question is: how and where can I catch errors from backgroundReload? Why not returning
promiseArray(_findAll(adapter, this, typeClass, sinceToken, options));
?The text was updated successfully, but these errors were encountered: