lib/mtx/server.js#L484 registers the per-tenant Object Store subscribe and unsubscribe handlers inside cds.on("listening", ...).
CAP Operator runs tenant operations via the cds-mtx CLI from @sap/cds-mtxs. That CLI calls cds.serve(...) and emits 'served' only (from bin/cds-mtx.js in @sap/cds-mtxs@3.9.0):
const { 'cds.xt.DeploymentService':ds, 'cds.xt.SaasProvisioningService':sps } = await cds.serve (services)
await cds.plugins
await _local_server_js()
await cds.emit('served', cds.services)
It never starts an HTTP listener, so 'listening' never fires, and the handlers are never attached. Subscribe completes successfully, zero Object Store instances are provisioned, no error, no log line. The "shared" branch's unsubscribe cleanup handler has the same problem.
Fix
Use 'served' instead. It's emitted by both cds.serve() (CLI) and cds-serve (long-running sidecar):
-cds.on("listening", async () => {
+cds.on("served", async () => {
Environment
@cap-js/attachments 3.12.1, @sap/cds 9.9.1, @sap/cds-mtxs 3.9.0, CAP Operator on Gardener with a TenantOperation workload.
lib/mtx/server.js#L484registers the per-tenant Object Store subscribe and unsubscribe handlers insidecds.on("listening", ...).CAP Operator runs tenant operations via the
cds-mtxCLI from@sap/cds-mtxs. That CLI callscds.serve(...)and emits'served'only (frombin/cds-mtx.jsin@sap/cds-mtxs@3.9.0):It never starts an HTTP listener, so
'listening'never fires, and the handlers are never attached. Subscribe completes successfully, zero Object Store instances are provisioned, no error, no log line. The"shared"branch's unsubscribe cleanup handler has the same problem.Fix
Use
'served'instead. It's emitted by bothcds.serve()(CLI) andcds-serve(long-running sidecar):Environment
@cap-js/attachments3.12.1,@sap/cds9.9.1,@sap/cds-mtxs3.9.0, CAP Operator on Gardener with aTenantOperationworkload.