This issue is a follow up on #251 , which apparently doesn't fix the handler's behavior in some situations.
I am currently still facing the behavior described in #251 using [email protected].
Here's the received response as breakpoint'd at https://github.com/kategengler/ember-cli-code-coverage/blob/master/lib/templates/test-body-footer.html#L22 (with some entries removed for readability)
{
"readyState": 4,
"requestHeaders": {
"Content-Type": "application/json; charset=utf-8"
},
"status": 200,
"statusText": "OK",
"method": "POST",
"url": "/write-coverage",
"async": true,
"responseText": "{\"lines\":{\"total\":493,\"covered\":432,\"skipped\":0,\"pct\":87.63},\"statements\":{\"total\":500,\"covered\":437,\"skipped\":0,\"pct\":87.4},\"functions\":{\"total\":167,\"covered\":138,\"skipped\":0,\"pct\":82.63},\"branches\":{\"total\":283,\"covered\":244,\"skipped\":0,\"pct\":86.22}}",
"response": "{\"lines\":{\"total\":493,\"covered\":432,\"skipped\":0,\"pct\":87.63},\"statements\":{\"total\":500,\"covered\":437,\"skipped\":0,\"pct\":87.4},\"functions\":{\"total\":167,\"covered\":138,\"skipped\":0,\"pct\":82.63},\"branches\":{\"total\":283,\"covered\":244,\"skipped\":0,\"pct\":86.22}}",
"responseXML": null,
"responseURL": "http://localhost:7357/write-coverage",
"sendFlag": true,
"responseType": "json",
"errorFlag": false
}As you can see, the responseType is json, yet the response and responseText are both Strings (both valid in their own rights).
I am a bit at a loss regarding the fix.
This does not really look like a bug from the handler to me, since a string is strictly speaking valid JSON.
Which makes me tempted to bring this to istanbul-lib-coverage.
On the other hand, a stupidly easy fix would be to restore some of the removed logic in this PR, specifically https://github.com/kategengler/ember-cli-code-coverage/pull/251/files#diff-94eab975fb48e219fc130d82e21457acL57-L58
I will validate the second option locally and if the results are satisfying on our fleet of repos using ember-cli-code-coverage, I will propose it here.
Meanwhile, I'm looking forward to your input and opinion on the best portion of the code to try and apply a fix.
This issue is a follow up on #251 , which apparently doesn't fix the handler's behavior in some situations.
I am currently still facing the behavior described in #251 using
[email protected].Here's the received response as breakpoint'd at https://github.com/kategengler/ember-cli-code-coverage/blob/master/lib/templates/test-body-footer.html#L22 (with some entries removed for readability)
{ "readyState": 4, "requestHeaders": { "Content-Type": "application/json; charset=utf-8" }, "status": 200, "statusText": "OK", "method": "POST", "url": "/write-coverage", "async": true, "responseText": "{\"lines\":{\"total\":493,\"covered\":432,\"skipped\":0,\"pct\":87.63},\"statements\":{\"total\":500,\"covered\":437,\"skipped\":0,\"pct\":87.4},\"functions\":{\"total\":167,\"covered\":138,\"skipped\":0,\"pct\":82.63},\"branches\":{\"total\":283,\"covered\":244,\"skipped\":0,\"pct\":86.22}}", "response": "{\"lines\":{\"total\":493,\"covered\":432,\"skipped\":0,\"pct\":87.63},\"statements\":{\"total\":500,\"covered\":437,\"skipped\":0,\"pct\":87.4},\"functions\":{\"total\":167,\"covered\":138,\"skipped\":0,\"pct\":82.63},\"branches\":{\"total\":283,\"covered\":244,\"skipped\":0,\"pct\":86.22}}", "responseXML": null, "responseURL": "http://localhost:7357/write-coverage", "sendFlag": true, "responseType": "json", "errorFlag": false }As you can see, the
responseTypeisjson, yet theresponseandresponseTextare both Strings (both valid in their own rights).I am a bit at a loss regarding the fix.
This does not really look like a bug from the handler to me, since a string is strictly speaking valid JSON.
Which makes me tempted to bring this to
istanbul-lib-coverage.On the other hand, a stupidly easy fix would be to restore some of the removed logic in this PR, specifically https://github.com/kategengler/ember-cli-code-coverage/pull/251/files#diff-94eab975fb48e219fc130d82e21457acL57-L58
I will validate the second option locally and if the results are satisfying on our fleet of repos using ember-cli-code-coverage, I will propose it here.
Meanwhile, I'm looking forward to your input and opinion on the best portion of the code to try and apply a fix.