Description
CDS 10 aligns the runtime behavior of req.reject and req.error with their documented contracts. In prior versions, some invocation forms or edge cases deviated from the documented behavior — for example, how error messages are propagated, whether additional data arguments are included in the error response, or how the HTTP status code is derived from the error argument. Applications that worked correctly only because they relied on the undocumented behavior may see different error responses after the upgrade.
How to Check
- [ ] Review all uses of
req.reject(...)andreq.error(...)in service handlers — verify that the arguments match the documented signature(httpStatus, message, target, args). - [ ] Run the full integration test suite against a CDS 10 environment and inspect any failures related to error response shape, HTTP status codes, or error message content.
- [ ] Check test assertions that validate error response bodies from HTTP requests that trigger
req.reject— the exact response structure may have changed. - [ ] Look for
req.rejectcalls that pass non-standard argument types (e.g. an object as the first argument, or four or more positional arguments).
Migration Steps
No automated detection is possible — run integration tests to identify regressions.
Align
req.rejectcalls with the documented signature:diff- req.reject({ code: 400, message: 'Invalid input' }); + req.reject(400, 'Invalid input');For
req.errorcalls that accumulate multiple errors (the non-throwing form), ensure the arguments follow the documented pattern:diff- req.error('Invalid field value', 'field/path'); + req.error(400, 'Invalid field value', 'field/path');After updating call sites, re-run the test suite and verify that HTTP error responses have the expected status codes and OData error body format.
Notes
The exact behavioral changes are not fully specified as of 2026-03-31 (issue github.tools.sap/cap/cdsnode/issues/2640 was still open). Verify against the final CDS 10 release notes for the specific deviations that were corrected. This entry should be revisited and confirmed once the issue is closed and the changes are documented.