Azure / Azure/azure-rest-api-specs

[BUG] Data Factory API spec returns PascalCase fields causing SDK unmarshalling failures (KeyName / VaultBaseUrl mismatch)

Open
#39,182 0 comments 0 reactions 0 assignees View on GitHub
bug customer-reported Data Factory Mgmt question Service Attention
Dominant language
TypeSpec
Stars
3.1k
Forks
5.9k
Avg merge
3d 2h
Merged PRs (30d)
424

Description

### API Spec link

https://github.com/Azure/azure-rest-api-specs/blob/8eb3f7a4f66d408152c32b9d647e59147172d533/specification/datafactory/resource-manager/Microsoft.DataFactory/stable/2018-06-01/datafactory.json

### API Spec version

2018-06-01

### Describe the bug

The Data Factory REST API returns encryption fields using PascalCase (`KeyName`, `VaultBaseUrl`, `KeyVersion`), but the API spec defines these fields as camelCase (`keyName`, `vaultBaseUrl`, `keyVersion`).

Because the SDK is generated from the spec, the Go SDK's `UnmarshalJSON` only recognizes camelCase keys, causing these fields to remain `nil` even when encryption is configured.

This behavior has been confirmed in SDK versions v8, v9, and v10.

Related SDK issue: https://github.com/Azure/azure-sdk-for-go/issues/25725

---

**Proposed Solution**

I would be happy to contribute a fix once the correct approach is confirmed.

Possible approaches include:
1. Update the API spec to use PascalCase field names (`KeyName`, `VaultBaseUrl`, `KeyVersion`)
2. Add explicit serialization metadata (e.g., `x-ms-client-name`) to align with actual REST API behavior

I am willing to open a PR once the maintainers advise which approach is appropriate.

### Expected behavior

The API spec should accurately reflect the casing used in the REST API response.

The encryption fields should be defined as:
- `KeyName` (not `keyName`)
- `VaultBaseUrl` (not `vaultBaseUrl`)
- `KeyVersion` (not `keyVersion`)

Alternatively, explicit serialization metadata should be added so SDKs can correctly unmarshal responses regardless of casing.

### Actual behavior

The REST API returns PascalCase fields:

```
{
"properties": {
"encryption": {
"KeyName": "my-cmk-key",
"VaultBaseUrl": "https://my-keyvault.vault.azure.com",
"KeyVersion": "abc123"
}
}
}
```

However, the SDK expects camelCase fields based on the spec, so all encryption fields are unmarshalled as `nil`.

This prevents applications from:
- Detecting whether CMK encryption is enabled
- Auditing encryption configurations
- Validating Data Factory security posture

### Reproduction Steps

1. Create an Azure Data Factory with CMK encryption enabled
2. Call the REST API to get the Data Factory properties:
az rest --method GET --url "https://management.azure.com/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.DataFactory/factories/{factoryName}?api-version=2018-06-01"
3. Observe that the response contains PascalCase fields (KeyName, VaultBaseUrl, KeyVersion)
4. Use the Azure Go SDK (v8/v9/v10) to retrieve the same Data Factory
5. Observe that the encryption fields are nil despite being set

### Environment

- Azure Go SDK versions: v8, v9, v10
- API version: 2018-06-01
- Verified using: az rest command

Contributor guide

Open the contributing guide

Research direction

Start with specification/datafactory/resource-manager/Microsoft.DataFactory/stable/2018-06-01/datafactory.json and inspect the encryption fields against the REST response shown in the issue. Confirm whether casing changes or serialization metadata is appropriate, then verify that generated Go SDK unmarshalling recognizes KeyName, VaultBaseUrl, and KeyVersion.

Written by the indexing model from the issue text.

Assessment

Tech stack
azure, go, openapi
Domain
api, cloud
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.