Open drvup opened 1 week ago
Hey @drvup, this has not changed in a long time and it is intended. When sending requests as batches you can send multiple changesets or retrieve requests together. When one of them fails, the total response will still be successful, but the individual responses underneath might indicate errors, much like Promise.allSettled()
. Ergo, if a changeset failed you will only see it in the subresponse for this changeset.
This also corresponds to the batch behavior on HTTP level (you will likely get a 202 status code on the batch request but an error code on the individual changeset).
I recommend to take a look at the docs for details on response handling with batch.
Please also note that changesets should be atomic, but every service owner could implement this differently...
Describe the bug We do send multiple requests in a batch to a SAP CAP application. Within, we do upsert different entities on the CAP app. It's working fine, but since some weeks, we discovered missing requests sent to our CAP app. We checked our logs and were wondering why there is nothing discovered. Today, we did debug this locally and identified, if a request inside a changeset as part of the batch send to CAP is rejected (e.g. the payload had a property who is not valid / existing), the SAP Cloud SDK is setting the changeset to
isSuccess
, instead ofisError
.To Reproduce Steps to reproduce the behavior:
Expected behavior The changeset is not successful, as the response from CAP is showing http status 400 for the request within the changeset. A changeset is always atomic. So, if one request inside a changeset is failing, the complete changeset is failing. We also do send a custom header: "prefer": "odata.continue-on-error" Having this customizing, the complete batch request is NOT failing, but the request due to the not-existing-property-thing, is failing. You can see the response for the request on the CAP app on the screenshot.
Screenshots
Used Versions:
Additional Information While debugging, I saw on file
odata-common/request-builder/batch/batch-response-deserializer.js
, as soon as it's a changeset, the deserialize methoddeserializeChangeSet()
does set theisSuccess
totrue
. From my POV, this should not be the case and there should be a check on the sub method, if the response is failed. I do wonder if this was never there and just discovered ( after 4 years running on production ) or if there was a code change in place.Impact / Priority Affected development phase: Production Impact: Inconvenience / Impaired
Best regards, Cedric