[BUG] OpenAPI compiler changes the value of @protocol annotation for CDS services

[mlakov]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

In the function _servicePath in ib/compile/index.js#L201 the value of the @protocol annotation of the given CDS service gets changed and is never restored to its original value. This means that using the OpenAPI compiler has unwanted side effects that change (and potentially break) CDS services for the entire runtime of an application.

Expected Behavior

Using the OpenAPI compiler does not result in unwanted / unexpected side effects.

Anything else?

Proposal for a fix:

function _servicePath(csdl, csn, protocols) {
  if (csdl.$EntityContainer && Array.isArray(protocols)) {
    const serviceName = csdl.$EntityContainer.replace(/\.[^.]+$/, "");

    return Object.fromEntries(
      protocols
        .map(protocol => { ...csn.definitions[serviceName], "@protocol: protocol })
        .map(service => [ service["@protocol"], cds.service.path4?.(service) || cds.serve.path4(service)])
    );
  }

  return {}
}

[mlakov]

Kudos to @zongqichen for pin-pointing the issue as a result of his investigation on cap-js/ord#543

[daogrady]

Hi @mlakov ,

thank you for your bug report. This is a duplicate of #169, so basically the same answer here: I don't believe we guarantee immutability.
I do acknowledge that this can be unexpected for callers, so we will introduce an initial call to cds.copy to mitigate this behaviour.

Can you please point out the tool chain in which you programmatically call the openapi converter, which then causes the mutation, just so I can understand what your workflow looks like? Thanks!

Best,
Daniel

[mlakov]

You can check the already linked PR -

[mlakov]

@daogrady as menitoned in the linked ticket - the issue surfaced as a result of an investigation @zongqichen did for an issue reported to the cap-js/ord plugin (see: here).

Within the ORD plugins (there's also a Java one) we're relying heavily on cap-js/openapi for executing JIT compilation of OpenAPI documents. These are collected from ORD aggregators and for productive applications one aggregation cycle typically includes (tens of) thousands of requests - one per each tennant for multi-tenant applications. The typicall workflow is:

• The ORD aggregator calls the ORD provider in the context of each application tenant
• The provider resolves the tenant specific CDS model (toggles, extensions etc) and generates ORD document based on it
• The aggregator requests all linked API resources from the returned document one at a time (OpenAPI resources are JIT compiled using cap-js/openapi).

This, of course, means that we're very cautious about the performance of these requests and how much memory / CPU they consume. Ideally it will be great if the CDS models are not being cloned each time but are treated as immutable from the cap-js/openapi plugin.

[daogrady]

Hi @mlakov ,

thank you for the update. I just did a performance analysis on cds.clone, which is basically just structuredClone, on various models.
For small models, the clone was created in a matter of microseconds. On a 10 MB model (which I would consider very large), it took 135 ms on my 2021 MacBook Pro on average.
In any case, this performance hit pales compared to the time needed to actually traverse the model and produce the openapi output. So the impact of calling cds.clone once per run is negligible.
Given that the openapi compiler, and by extension the ord plugin, are design time tools, this should be well within reasonable times for them to finish.
The change will be done in #187 and is ready, but it will not be merged before next week. Feel free to try it out locally to confirm it addresses the underlying issue.

Best,
Daniel