CDS compiler bug for OpenAPI generates invalid count properties for OData and REST services

[#1]

I faced an issue where CAP generated incorrect OpenAPI specs and the API response which was a bit irritating for my frontend team. Therefore I created a minimal CAP/SQLite reproduction for a count-related OpenAPI issue: https://github.com/purplepenguino/cds-openapi-bug

The service uses a simple Authors/Books model and exposes both OData V4 and REST endpoints.
The generated OpenAPI documents describe collection responses using properties such as:

• value
• @count
• books@count

However, the runtime/ server responses use different formats:

• OData returns @odata.count and [email protected].
• REST returns a bare array without $count=true.
• REST returns an object containing count and value when $count=true.
• REST expanded counts also use [email protected].

The generated REST and OData schemas are currently almost identical apart from the server URL, even though the runtime response formats differ. The generated $top schema also does not document the effective limit or a continuation mechanism.

Protocol/request	Generated OpenAPI spec	Actual server response
OData collection with $count=true	Object with value and @count	Object with value and @odata.count
OData expansion with $count=true	books@count	[email protected]
REST collection without $count=true	Object with value	Bare JSON array
REST collection with $count=true	Object with value and @count	Object with value and count
REST expansion with $count=true	books@count	[email protected]

Again, you can find the reproduction in this repo here: https://github.com/purplepenguino/cds-openapi-bug

Environment:
@SAP/cds 10.0.5
@SAP/cds-compiler 7.0.3
@SAP/cds-dk 10.0.7
@cap-js/sqlite 3.1.0
Node.js 24.x

The expected fix would be in the CAP runtime/OpenAPI generation that each protocol’s generated schema accurately describes its actual response format :).