Skip to Content
7
Oct 27, 2022 at 03:22 PM

Is the CAP Error Handling approach of "Let It Crash" the right one?

657 Views

Hello SAP CAP Developers,

in the CAP documentation we find the Gudeline for Error Handling defined as "Let It Crash". But is that the right approach when providing a Multitenant SaaS Backend? Of course I will have multiple instances of my service layer to support the load and get zero downtime blue green deployments. But each of this instances will handle still requests of multiple clients at the same time. When now one user triggers an error that crashes the whole instance all clients will receive a network error.

This behaviour is implemented in @sap/cds/libx/_runtime/cds-services/adapter/odata-v4/handlers/error.js. For the current request a rollback is executed:

const getErrorHandler = (crashOnError = true, srv) => {
  return async (odataReq, odataRes, next, err) => {
    // REVISIT: crashOnError
    if (isStandardError(err) && crashOnError) {
      // first rollback in case of atomicity groups
      const changeset = odataReq.getAtomicityGroupId()
      if (changeset) {
        const tx = odataReq.getBatchApplicationData().txs[changeset]
        await tx.rollback().catch(() => {})
      }

      throw err
    }

and crashes the instance when this error types occur:

const isStandardError = err => {
  return (
    err instanceof TypeError ||
    err instanceof ReferenceError ||
    err instanceof SyntaxError ||
    err instanceof RangeError ||
    err instanceof URIError
  )
}

module.exports = { isStandardError }

But what happens with the DB Transactions started by other clients? Is it the job of the database to rollback that transactions? Does HANA behave like this?

Best Regards
Gregor