Azure / Azure/azure-rest-api-specs
Aggregation columns are always returned in alphabetical order, but columns list not updated to reflect this
- Dominant language
- TypeSpec
- Stars
- 3.1k
- Forks
- 5.9k
- Avg merge
- 3d 37m
- Merged PRs (30d)
- 446
Description
- **Package Name**: azure-mgmt-costmanagement
- **Package Version**: 3.0.0
- **Operating System**: Linux
- **Python Version**: 3.10.8
**Describe the bug**
When performing a `query.usage` for a given scope, if you define an aggregation
**To Reproduce**
Steps to reproduce the behavior:
1. create a QueryDefinition with the following aggregation
```
aggregation=dict(
UsageQuantity=AzureModels.QueryAggregation(
name='UsageQuantity',
function=AzureModels.FunctionType.SUM
),
Cost=AzureModels.QueryAggregation(
name='Cost',
function=AzureModels.FunctionType.SUM
),
),
```
2. when returned, note how the `results.col.umns` will say the `UsageQuantity` is the first column, but the values presented are actually `Cost`.
3. Swap `UsageQuantity` and `Cost` in the aggregation and submit again. You'll notice that the `results.columns` say the first column is now `Cost`, but the `results.rows` lists didn't change their values.
4. Reconcile the data returned from the API with information in the Azure Portal on a daily basis to confirm
**Expected behavior**
I would expect the aggregation to return in the same order it's defined and have the correct values. At a minimum, I'd expect the `results.columns` to accurately reflect what was returned from the API call.
**Screenshots**
n/a
**Additional context**
The same behavior appears to happen on the web API as well, perhaps this is a defect with the backend service?
https://learn.microsoft.com/en-us/rest/api/cost-management/query/usage?tabs=HTTP
Contributor guide
Research direction
Start with the QueryDefinition aggregation example and compare the results.columns metadata with the results.rows values, then consult the linked Azure Cost Management query/usage REST API documentation. Done means determining whether the mismatch is represented in the API specification or belongs to the backend service, with the affected contract or service behavior clearly identified.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure, python
- Domain
- api, cloud
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100