[Logic Apps Hybrid] Adding a File System connection is not idempotent / doesn't safely preserve existing volume mounts (duplicates & corrupts azurestorageaccounts/template.volumes)

[takyyon]

Platform

Azure Logic Apps Hybrid (Azure Container Apps on connected/Arc environment). A parallel non-hybrid (Logic Apps Standard on App Service, Microsoft.Web/sites/config/azurestorageaccounts) path exists in the same client and is noted below.

Summary

Adding a new File System connection mutates the container app's template.volumes / template.volumeMounts (hybrid) or azurestorageaccounts (Standard) in a way that does not safely preserve prior mounts, corrupting existing volume-mount configuration (including, in combination with #9438, the reserved /home/site/wwwroot mount).

Where it happens (code)

FileSystemConnectionCreationClient.ts — same files as #9438:

• AzureUX-LogicAppsPortal: src/Extension/Client/React/Services/FileSystemConnectionCreationClient.ts (+ CodelessWorkflows/Services/ mirror).
• LogicAppsUX: apps/Standalone/src/designer/app/AzureLogicAppsDesigner/Services/FileSystemConnectionCreationClient.ts.

Hybrid branch (~L167–247)

const newVolumes = [ { name: fileShareName, storageName: fileShareName, storageType: 'Smb' },
                     ...containerAppResponse.properties.template.volumes ];
const newVolumeMounts = [ { volumeName: fileShareName, mountPath: `/mounts/${fileShareName}` },
                          ...containerAppResponse.properties.template.containers[0].volumeMounts ];

Problems:

1. Not idempotent — it unconditionally prepends. Re-saving the same connection, or reusing a displayName, appends duplicate volumes/volumeMounts entries for the same share.
2. Only containers[0] is updated; mounts on other containers are dropped when the reconstructed template is PATCHed back.
3. The reconstructed template becomes the write-back source of truth (see [Logic Apps Hybrid] File System connection save PATCHes the container app and drops/repoints the /home/site/wwwroot volume mount, app fails to start #9438), so any drift drops existing mounts.

Non-hybrid branch (~L248–285)

const response = await httpClient.post(configFetchUrl, ...);        // POST azurestorageaccounts/list
response.properties[connectionName] = newFileShareConfig;           // merge
await httpClient.put(configBaseUrl, response, ...);                 // PUT full collection

This read-modify-writes the whole azurestorageaccounts dictionary. It preserves other entries only if the /list response returns every existing share with a usable accessKey; any masked/omitted entry is corrupted on write-back. Also emits a Windows-style mount path (\mounts\<name> → C:\mounts\<name>) which is invalid for Linux Logic Apps Standard.

Suggested fix direction

• Key each mount by a stable connector-specific name and add/update only that entry (idempotent re-save); never blind-prepend.
• Preserve every existing volume/volumeMount (all containers) and never touch /home/site/wwwroot (see [Logic Apps Hybrid] File System connection save PATCHes the container app and drops/repoints the /home/site/wwwroot volume mount, app fails to start #9438).
• Non-hybrid: verify /list returns all shares with resolvable keys before PUT; emit an OS-appropriate mountPath (POSIX on Linux).

Impact

High — File System connectors are not composable (duplicate/broken mounts), and existing mounts (incl. the runtime content mount) can be corrupted.

References

• Internal work item: https://msazure.visualstudio.com/Antares/_workitems/edit/38598433
• Related: [Logic Apps Hybrid] File System connection save PATCHes the container app and drops/repoints the /home/site/wwwroot volume mount, app fails to start #9438 (save drops/repoints the /home/site/wwwroot mount).