Azure / Azure/azure-rest-api-specs
[BUG] Data Factory API spec returns PascalCase fields causing SDK unmarshalling failures (KeyName / VaultBaseUrl mismatch)
- 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
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