cds.Request is build up from payload containing query and data, which disconnects both

[oklemenz2]

Use-Case. In an insert query, the following must hold true:

req.query.INSERT.entries[0] === req.data

Event queue serializes req, and stores as payload. During deserialization data and query get disconnected, so that the following assumption does not hold true.

This leads to failures later as for example @readonly keys (ID) are not filled, leading to not null exceptions on DB.

SOLUTION:

Code @cap-js-community/event-queue/src/outbox/EventQueueGenericOutboxHandler.js must build up the relationship again from parsed JSON. So that for req.data is bound again to the query.

This happens automatically, when data is not part of the payload during building of cds.Request.

So it needs to be checked what type of query it is, and if it holds the data already in the query, so that req.data is redundant and can be skipped?

Pseudocode for INSERT

if (payload.query?.INSERT) {
  delete payload.data; // data is build up from `req.query.INSERT.entries[0]`
}

Similar may be necessary for other queries.... UPDATE, UPSERT, etc...

[soccermax]

I'm wondering if query is the only property we need to give a special treatment?
I just checked and req.params is currently not stored. --> So I'll add this as well

Understood I'll build up a testsetup for all queries and check what needs to be done

[oklemenz2]

Yes, definitely. Maybe it makes sense to check default CAP outbound behavior, how they do it for all cases...

[oklemenz2]

A quick fix for INSERT would be cool, to unblock my use-case ;-)