Azure / Azure/azure-rest-api-specs

Aggregation columns are always returned in alphabetical order, but columns list not updated to reflect this

Open
#21,707 3 comments 0 reactions 0 assignees View on GitHub
Cost Management - Query customer-reported Mgmt needs-triage question
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.