Azure / Azure/azure-dev

Aspire: services.<name>.apiVersion is never propagated to synthesized services — #6092's documented workaround is unreachable for Aspire apps (BindingType 'Auto' unmarshal)

Open
#8,601 1 comment 0 reactions 0 assignees View on GitHub
area/aspire bug customer-reported
Dominant language
Go
Stars
569
Forks
364
Avg merge
2d 19h
Merged PRs (30d)
136

Description

- [x] Make sure you've installed the latest version using [instructions](https://github.com/Azure/azure-dev?tab=readme-ov-file#installupgrade-azure-developer-cli)

**Output from `azd version`**
azd version 1.25.5 (also reproduced on 1.25.2)

**Describe the bug**

This is the **Aspire-specific half of #6092**. When a container app's stored state contains `bindingType: 'Auto'` (the ACA-recommended way to declare custom domains in IaC, per microsoft/azure-container-apps#796), `azd deploy` fails its post-apply read:

```text
ERROR: getting container app: unmarshalling type *armappcontainers.ContainerApp: ... struct field BindingType: json: cannot unmarshal number into Go value of type armappcontainers.BindingType
Suggestion: set 'apiVersion' on your service in azure.yaml to match the API version in your IaC
```

For non-Aspire services the suggested `services..apiVersion` workaround works (#6092). **For Aspire AppHost apps it does not**: the Aspire importer synthesizes one service per Aspire resource and never copies `ApiVersion` onto them, so the custom api-version policy never reaches the failing GET.

**Source pointers (main as of 2026-06-10):**

- `cli/azd/pkg/project/dotnet_importer.go` — every synthesized `ServiceConfig{...}` (three construction sites) omits `ApiVersion`; the file contains zero references to it, even where the parent azure.yaml service config (`svcConfig`) is in scope.
- `cli/azd/pkg/project/service_target_dotnet_containerapp.go` — *does* consume `serviceConfig.ApiVersion` (two `ContainerAppOptions{ApiVersion: ...}` sites), so the plumbing exists on both sides of the gap; only the copy is missing.
- Root cause of the unmarshal itself: `cli/azd/go.mod` pins `armappcontainers/v3 v3.1.0`, whose default api-version predates `Auto` (introduced `2024-10-02-preview`); the RP then returns `bindingType` as a number, which the SDK's string-typed enum rejects.

**To Reproduce**

1. Aspire AppHost app deployed to ACA via azd, with a module bicep declaring `ingress.customDomains: [{ name: '', bindingType: 'Auto' }]` at `Microsoft.App/containerApps@2025-02-02-preview` (or any version ≥ 2024-10-02-preview).
2. Add the suggested workaround to azure.yaml:

```yaml
services:
app:
language: dotnet
project: ./src/My.AppHost/My.AppHost.csproj
host: containerapp
apiVersion: 2025-02-02-preview
```

3. `azd deploy` → the service's bits and bicep apply successfully, then the post-apply read fails with the unmarshal error above, **and the remaining services in the run are cancelled**.

We reproduced this twice (with and without the apiVersion pin) on a three-service Aspire app; live ARM state confirmed the deployments themselves had fully applied each time — only azd's read-back fails, which makes the failure particularly misleading.

**Expected behavior**

Either of:

1. `dotnet_importer.go` copies `ApiVersion` from the azure.yaml service onto each synthesized `ServiceConfig` (appears to be a one-line fix per construction site), or
2. `armappcontainers` is bumped to ≥ v4 so `Auto` round-trips without a custom api-version.

**Workaround we're using**

Deploy per service and treat only this exact post-apply signature as a soft failure, with outcome gates (a `/version`-vs-tag assertion + an outside-in TLS check) arbitrating real success:

```bash
for svc in svc-a svc-b svc-c; do
if azd deploy "$svc" --no-prompt 2>&1 | tee "/tmp/azd-$svc.log"; then
echo "$svc: deployed"
elif grep -q "cannot unmarshal number into Go value of type armappcontainers.BindingType" "/tmp/azd-$svc.log"; then
echo "$svc: known Auto-binding read bug; deployment applied — downstream gates verify"
else
exit 1
fi
done
```

**Environment**
GitHub Actions ubuntu-latest (Azure/setup-azd@v2, latest) and macOS 15; Aspire 13.1.0 AppHost; materialized infra (`azd infra gen` + hand-maintained modules); `Microsoft.App/containerApps@2025-02-02-preview`.

Related: #6092 (non-Aspire report + workaround), #5109 (api-version mismatch design), microsoft/azure-container-apps#796 (`Auto` binding type), microsoft/azure-container-apps#1652 (platform-side Auto regression history).

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.