-
-
Notifications
You must be signed in to change notification settings - Fork 80
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
Adapter mixin causes error when API returns empty object & 204 #107
Comments
hey @simonihmig! Seems like something that should be changed in Mirage. According to httpstatus, The logic in ember-fetch assumes that a 204 is being implemented this way |
@nlfurniss hey, yes, I should probably create an issue for mirage as well. But I nevertheless think this could maybe be handled a bit better here as well, i.e. ignore any payload in the adapter mixin for a 204 response. Don't you think? |
I just want to mention that we are moving fetch support to Ember Data itself : emberjs/data#5386 |
Hi @simonihmig
But the PR (it's same as now) you linked, the handling is to return if (response.ok && (status === 204 || status === 205 || requestData.method === 'HEAD')) {
payload = { data: null };
} Is it the expected output? Or the payload should be an empty string in 204 case? |
Closing this, as this has been fixed in Mirage, and the fetch adapter mixin is deprecated anyway. |
Getting this ember-data error after migrating to fetch and using the adapter mixin:
Assertion Failed: normalizeResponse must return a valid JSON API document: One or more of the following keys must be present: "data", "errors", "meta".
This happens when the API returns a 204 response, but with an empty objects as the payload (
"{}"
). Our real API actually doesn't do this, but Mirage's default handler forDELETE
calls seems to return this.It seems this was caused by #60, which changed the way a 204 response is handled in
determineBodyPromise()
.jQuery's ajax seems to handle this differently. The raw xhr object has a status of 204 and
"{}"
as theresponseText
, but the success hook nevertheless receivesundefined
as the payload, as can be seen on this screenshot:To be a drop-in replacement, I think this should behave the same way as before, i.e. return
undefined
(or maybe{ data: null }
as it was before)!?The text was updated successfully, but these errors were encountered: