Currently we overcome this by ignoring it on the application side (sCount.replace(/\r?\n|\r/,'') === '0'), but as this is not required when working with the real CAP backend we would of course prefer if the mockserver would not add the CR + LF so that the mockserver specific code is not needed in the application.
Expected results
response: '0'
Actual results
response: '0\r\n'
Screenshots
Version/Components/Environment
Add any other context about the problem here
OS:
[ ] Mac OS
[X] Windows
[ ] Other
Root Cause Analysis
Problem
{describe the problem}
Fix
{describe the fix}
Why was it missed
{Some explanation why this issue might have been missed during normal development/testing cycle}
How can we avoid this
{if we donβt want to see this type of issues anymore what we should do to prevent}
hey hey ππ»
A
$count
query (at least for an odata v2 request) does not only return the actual count but also '\r\n'.Sample:
request:
MyEntity/$count?$filter=name%20eq%20%27Foo%27%20and%20id%20ne%20guid%27b31b9366-7843-4515-a46d-ac197a6c49b0%27
response:
'0\r\n'
Currently we overcome this by ignoring it on the application side (
sCount.replace(/\r?\n|\r/,'') === '0'
), but as this is not required when working with the real CAP backend we would of course prefer if the mockserver would not add the CR + LF so that the mockserver specific code is not needed in the application.Expected results
response:
'0'
Actual results
response:
'0\r\n'
Screenshots
Version/Components/Environment
Add any other context about the problem here OS:
Root Cause Analysis
Problem
{describe the problem}
Fix
{describe the fix}
Why was it missed
{Some explanation why this issue might have been missed during normal development/testing cycle}
How can we avoid this
{if we donβt want to see this type of issues anymore what we should do to prevent}