[Logic Apps Hybrid] File System connection save PATCHes the container app and drops/repoints the /home/site/wwwroot volume mount, app fails to start
- Dominant language
- TypeScript
- Stars
- 111
- Forks
- 109
- Avg merge
- 1d 23h
- Merged PRs (30d)
- 20
Description
## Platform
**Azure Logic Apps _Hybrid_** (runtime hosted on Azure Container Apps via a connected/Arc environment + custom location). Confirmed by internal repro (ADO 38598433). A parallel non-hybrid (Logic Apps Standard on App Service) path exists in the same client and is noted below.
## Summary
Saving/creating a **File System** connection issues a raw ARM `PATCH` on the container app in which the **`/home/site/wwwroot` volume mount is removed and its `mountPath` is repointed to the file-share mount** instead. The runtime then can't find `/home/site/wwwroot` (host.json, workflow content), and **the app fails to come up**.
Internal repro (ADO 38598433, "[LA Hybrid] – App setting update is corrupting the volume mount configuration"):
> the portal is messing up the volume mount in the PATCH request (removing `/home/site/wwwroot` and setting it to the fileshare name instead).
## Where it happens (code)
`FileSystemConnectionCreationClient.ts`, hybrid branch:
- **AzureUX-LogicAppsPortal** (prod portal, ADO): `src/Extension/Client/React/Services/FileSystemConnectionCreationClient.ts` — `connectionCreationFunc`, `if (isHybrid)` (~L167–247). A mirror also exists at `src/Extension/Client/CodelessWorkflows/Services/FileSystemConnectionCreationClient.ts`.
- **LogicAppsUX** (OSS designer): `apps/Standalone/src/designer/app/AzureLogicAppsDesigner/Services/FileSystemConnectionCreationClient.ts`.
The flow:
1. `GET` the container app and **reconstruct a partial payload** — keeping only `location`, `extendedLocation`, `properties.environmentId`, and `properties.template.{volumes, containers[].{name,image,volumeMounts,env}}` (drops `properties.configuration`, `workloadProfileName`, `managedEnvironmentId`, `tags`, `systemData`, and any container fields beyond the four mapped) (~L176–190).
2. Prepend the new share to `volumes`/`volumeMounts` (~L216–230).
3. Raw `PATCH` the reconstructed object back via `corsFetch` (~L232–241).
## Root cause (hypothesis, code-grounded)
The client **reconstructs and re-sends the whole `template`** from a client-side GET rather than sending a minimal, additive delta. Because the reconstructed `template.volumes`/`volumeMounts` become the source of truth on write-back, any staleness or drift in the fetched revision — or a sibling flow that also reconstructs the template (e.g. the app-settings update path in the ADO repro) — results in the reserved `/home/site/wwwroot` mount being dropped or repointed. Reconstruct-and-PATCH of `template` is inherently fragile for a resource whose volume mounts must be preserved exactly.
## Suggested fix direction
- Do not reconstruct the container-app `template`. Re-fetch the latest revision and send an **additive** change that preserves **all** existing `volumes`/`volumeMounts` (and every other `template`/`configuration` field), keyed by a stable connector-specific volume name so the reserved `/home/site/wwwroot` mount is never touched.
- Guard the reserved mount explicitly (never emit a `volumeMount` whose `mountPath` is `/home/site/wwwroot` for a connector volume).
- Handle all containers, not only `containers[0]`.
## Impact
**High** — the app becomes unbootable after saving a File System connection (or, per the ADO repro, after an app-settings update on a hybrid app). Runtime is down until the mount is restored.
## References
- Internal work item: https://msazure.visualstudio.com/Antares/_workitems/edit/38598433 ("[LA Hybrid] – App setting update is corrupting the volume mount configuration", State: Done — but the File System connector path exhibits the same reconstruct-and-PATCH fragility).
- Companion issue: #9439 (adding a new File System connector duplicates/overrides existing volume mount settings).
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the hybrid branch of connectionCreationFunc in src/Extension/Client/React/Services/FileSystemConnectionCreationClient.ts, then compare the mirror files named in the issue. Trace the GET, template reconstruction, and corsFetch PATCH, checking how volumes and volumeMounts are handled across containers. Done means saving a File System connection preserves the existing /home/site/wwwroot and other mounts, and the app still starts.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure, typescript
- Domain
- cloud, frontend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100