[Version: 3.13.2] BREAKS tenant upgrade with ScanStates_texts locale-CSV merge conflicts with incremental HDI upgrade

[huulanka]

Description

Upgrading from 3.13.1 to 3.13.2 broke tenant upgrades on an existing BTP/HANA Cloud multitenant (MTX) landscape for us. The upgrade task on the MTX sidecar app fails for every already-provisioned tenant with an HDI table-import conflict on ScanStates_texts, the seed data table for the attachments plugin's malware-scan-status texts.

Looking at what changed between the two versions: 3.13.1 ships the ScanStates_texts translations as ~35 separate per-locale CSVs (sap.attachments-ScanStates_texts_de.csv, _ar.csv, _bg.csv, ...), each of which compiles to its own .hdbtabledata with an include_filter scoped to that locale, plus one base sap.attachments-ScanStates_texts.csv containing only en. In 3.13.2 all of those per-locale files are gone and every locale's rows have been folded into the single base CSV, which now compiles to a .hdbtabledata with no include_filter at all.

That's a perfectly fine layout for a fresh HDI container. The problem is on upgrade of an existing container: our tenant upgrade goes through cds.xt.DeploymentService with skipResources: true (the default incremental upgrade path), and it only detects the 2 files that actually changed/were added — it does not pick up the ~35 removed per-locale files as needing undeploy ("0 files to undeploy" in the log below). So after the bump, both the old locale-specific .hdbtabledata files (still present in the container from the 3.13.1 deploy, each with their own include_filter) and the new base .hdbtabledata (no include_filter, so it tries to claim every key including de, ar, bg, ...) exist side by side and target the same table. HDI's own consistency check then rejects the deploy outright.

Reproduction

1. Have an existing BTP Cloud Foundry / HANA Cloud MTX app on @cap-js/attachments@3.13.1 with at least one subscribed tenant (so the per-locale ScanStates_texts_*.hdbtabledata artifacts are already deployed to its HDI container).
2. Bump @cap-js/attachments to 3.13.2 only (no other changes).
3. Deploy via the standard MTA pipeline / cf deploy, which triggers the upgrade task against existing tenants.
4. Tenant upgrade fails.

We hit this via a routine Dependabot bump PR, so there's no exotic setup involved — just an ordinary "existing tenant, patch bump, redeploy."

Expected behavior

A patch-level bump should not break upgrades for tenants that were already provisioned on the previous version, or at minimum the incremental/skipResources upgrade path should correctly compute the full set of files to undeploy when source files are removed between versions.

Actual behavior

The upgrade task fails for every existing tenant with:

Error: com.sap.hana.di.tabledata: The "include_filter" definitions in the table import files
"src/gen/data/sap.attachments-ScanStates_texts_ar.hdbtabledata" and
"src/gen/data/sap.attachments-ScanStates_texts.hdbtabledata" use key values that are not
disjunct; "src/gen/data/sap.attachments-ScanStates_texts.hdbtabledata" defines no
"include_filters" which prohibits other imports from importing into the same table [8251512]
Error: Worker 3 has encountered an error; all remaining jobs will be canceled [8214600]
Error: com.sap.hana.di.tabledata: The "include_filter" definitions in the table import files
"src/gen/data/sap.attachments-ScanStates_texts_bg.hdbtabledata" and
"src/gen/data/sap.attachments-ScanStates_texts.hdbtabledata" use key values that are not
disjunct; ...

and further down:

Error: Starting make in the container "D80D5BF17F11459F834EBD8184E1517F" with 2 files to
deploy, 0 files to undeploy... failed [8214168]
Deployment to container D80D5BF17F11459F834EBD8184E1517F failed - error: HDI make failed

Note the "0 files to undeploy" — the ~35 removed per-locale CSV/.hdbtabledata files from 3.13.1 are not being reconciled at all during this incremental upgrade.

Because our MTA has abortOnError: false, the rest of the deploy (app restart etc.) still completed, so the running app itself is fine, but the HDI containers for our existing tenants never actually got upgraded — the transaction never committed, so no data was lost, but the tenants are stuck on the old schema until this is resolved. We've reverted to 3.13.1 for now.

Environment

@cap-js/attachments (broken)	3.13.2
@cap-js/attachments (last known good)	3.13.1
@sap/cds	10.0.4
@sap/cds-dk	10.0.5
@sap/cds-mtxs	4.0.1
@sap/hdi-deploy	5.7.0
@sap/hdi	4.8.1
Node.js	20 (Cloud Foundry buildpack), 26 locally
Deployment target	Cloud Foundry / HANA Cloud, multitenant via @sap/cds-mtxs, MTA-based deploy

[github-actions]

👋 Hello @huulanka, thank you for submitting this issue. Our team is reviewing your report and will follow up with you as soon as possible.

[eric-pSAP]

Hi @huulanka,

You will need to specify the deleted CSV files in the undeploy.json to allow HDI to undeploy the old .texts CSV files. There may also be an auto undeploy option to automatically undeploy non-existent artifacts. We apologize for the inconvenience caused by this but feel free to let us know any other problems you have in the future!

[huulanka]

Hi @eric-pSAP , thanks for the fast reply.

Happy to add the undeploy entries on our side. Just wanted to flag that this was a patch bump (3.13.1 → 3.13.2), and we only found out about the needed undeploy.json entries after it broke tenant upgrades in production. Would it be possible to add a quick migration note to the changelog for cases like this, so the next person upgrading doesn't hit the same surprise? Totally understand these things happen - just trying to save someone else the debugging session

[eric-pSAP]

@huulanka,

Good idea, we will go ahead an add in a migration note for others to use. Thanks again!