Repository navigation
Billing product list fails on date format returned #34082
Description
Activity
- addedcustomer-reportedIssues that are reported by GitHub users external to the Azure organization.Issues that are reported by GitHub users external to the Azure organization.
on Sep 15, 2026 Thank you for opening this issue, we will look into it.
- addedBillingaz billingaz billingService AttentionThis issue is responsible by Azure service team.This issue is responsible by Azure service team.
on Sep 15, 2026 - addedRequest X Engineering AgentRequest X Engineering Agent testing and reviewRequest X Engineering Agent testing and review
on Sep 16, 2026 x-engineering-agent commented
on Sep 16, 2026 ContributorMore actionsBug Analysis
Affected CLI module:
billing, insrc/azure-cli/azure/cli/command_modules/billing/.
Target repository / branch:Azure/azure-cli/dev.
Use this EXACT PR title:[Billing] Fix #34082:az billing product list: Handle non-ISO product datesReproducer and expected result
The report is sufficiently specified; no additional customer information is needed to begin a regression-driven fix. Its discussion contains an acknowledgement and no prior requirements request or bug analysis.
- Reported environment: Azure CLI 2.90.0, Python 3.12.14, RPM installation in Cloud Shell on Microsoft Azure Linux 3.0.
- Failing command:
az billing product list --account-name <billing-account> --profile-name <billing-profile>. - The service returns Product properties including
purchaseDate: "12/02/2024"andendDate: "10/01/2026". Other reported purchase dates include09/17/2025and10/13/2025, supporting month/day/year rather than locale-dependent day/month interpretation. - Actual behavior: materializing the paged result fails in
ProductsOperations.extract_data, while deserializingProductsListResult/Product, withazure.core.exceptions.DeserializationErrorandValueError: Invalid datetime string: 12/02/2024frommsrest.serialization.deserialize_iso. - Expected behavior: list all products in the requested billing account/profile without a traceback, preserving their fields and normal CLI JSON output. This is a response-deserialization failure, not invalid command arguments or merely display formatting.
Grounded source context
Inspected upstream
devat 79fa755; verify against the implementation job's pinned base before changing anything.src/azure-cli/setup.py(line 75) pinsazure-mgmt-billing==6.0.0.billing/generated/commands.py(lines 97-106) registersbilling product listasbilling_product_listwithProductsOperationsandcf_product.generated/_client_factory.py:51-52returnsBillingManagementClient.products.billing/generated/custom.py(lines 310-329) selectsclient.list_by_billing_profile(...)for the exact reported arguments. It returns the SDK pager unchanged. Other branches select invoice-section, customer, or billing-account scope. The traceback shows the exception occurs later, when CLI consumes that pager, before a usable Product model exists.- The inspected product path is legacy AutoRest/SDK-backed, not the separate AAZ billing-period path.
billing/custom.pyimportsgenerated.custombeforemanual.custom;billing/__init__.py:42-45loads generated registrations beforemanual.commands. These are existing handwritten override points.billing/manual/custom.pyandmanual/commands.pyalready contain scoped Billing overrides. test_billing_scenario_incrementalGenerated.py(lines 631-655) has account/profile/invoice-section product-list examples with empty checks. That generated smoke coverage does not establish handling of the reported response payload. Handwritten scenario coverage also exists intests/latest/test_billing_commands.py.
Focused implementation requirements
- Fix the product-list response compatibility boundary, not the shared
msrestISO parser. Confirm the pinned SDK's Product date mappings and supported transport/deserialization hooks. Prefer a narrowly scoped handwritten compatibility adapter throughbilling/manual/custom.pyand, only if necessary,manual/commands.pyor another handwritten module-local helper. - The adapter must handle the reported date representation before Product deserialization on every page. A post-deserialization output transform, or a try/except covering only pager construction, cannot fix the observed lazy-iteration failure. Preserve standard ISO-8601 timestamps and missing/null optional fields. If normalizing slash dates, use strict calendar-valid month/day/year semantics only for the affected Product date fields; avoid machine-locale guessing, whole-response string replacement, and invented timezone shifts.
- Preserve account/profile/invoice-section/customer routing, filters, request parameters, next-link traversal, ordinary CLI field names and output shape. Do not silently discard products or swallow malformed payloads, service failures, or continuation-page errors. Do not change update/move operations, status/auto-renew transitions, global SDK model attribute maps, or other modules' deserializers as a side effect.
- Do not hand-edit
generated/, SDK-generated models/operations,aaz/, generated scenario files, or generation archives. If the correct fix instead changes the API schema or generated SDK/AAZ model, change its approved durable source and execute the owning regeneration/release workflow. Report an unavailable source/generator/dependency as a blocker rather than fabricating generated output or broadening this into an unrelated migration. The handwritten override route must remain clearly distinct from generated artifacts.
Required regression and scenario coverage
Add focused handwritten tests under
billing/tests/latest/, using the repository's existing test infrastructure:- Drive a realistic mocked HTTP response through the pinned Billing SDK's real
ProductsListResult/ Product deserialization and consume its actual pager. Reproduce the reported failure withpurchaseDate=12/02/2024and slash-formendDate, then prove the command returns complete, JSON-serializable products after the fix. Do not mock away the deserializer or prove only that arguments were forwarded. - Cover mixed ISO-8601 timestamps (including offsets/fractional seconds), reported month/day dates including unambiguous
09/17/2025, null/missing dates, empty product lists, invalid dates, and unchanged unrelated Product fields. Assert calendar dates and output representation explicitly, including the month/day choice for12/02/2024. - Use at least two pages: a valid first page and a continuation page containing the original offending date. Assert every product appears once, continuation handling terminates correctly, and failure on a later page is not converted into a misleading successful partial list. Include relevant HTTP/service-error propagation.
- Exercise the actual command/profile branch and verify account, invoice-section, and customer routing/filter semantics are not regressed by shared adaptation. Include an unaffected Billing path to detect global serializer/model mutations. Use synthetic identifiers and reusable sanitized fixtures, never customer values.
- Run focused existing
azdev style,azdev linter, and Billing tests during implementation. A live Billing scenario, when authorized fixtures and credentials are available, usesazdev test billing --live --series; deterministic transport/deserialization regression coverage remains required even when live credentials are unavailable. Record the actual validation results and any live-environment limitation.
Dispatch boundary: This analysis authorizes a durable Foundry implementation assignment only. No implementation, local project tests, CI/workflow dispatch, approval, or merge was performed during this triage.
Mandatory Codegen execution protocol
Before editing implementation files, determine whether the affected
billingcommand is AAZ-generated. Files underaaz/<profile>/are generated output and must never be patched directly, including by an AI agent. Check outAzure/aazbesideAzure/azure-rest-api-specs,Azure/aaz-dev-tools, and the downstream repository. API-schema defects start in the specification; command naming, grouping, arguments, API-version selection, help, and examples belong in the durableAzure/aazcommand model; non-modelable client behavior belongs in a handwritten subclass or wrapper incustom.py, registered fromcommands.py. X Engineering Agent creates and promotes the corresponding durableAzure/aazsource pull request before it promotes downstream generated output.Follow the Azure CLI repository's Codegen workflow and the aaz-dev setup documentation. Set up the checked-out repositories with
azdev setup. Usegenerateonly when importing or redesigning command models from Swagger/TypeSpec. For an existing module whose durableAzure/aazmodel has been updated, render that model withregenerate:aaz-dev cli regenerate --name billing --cli-path <azure-cli> # New/imported command model only: aaz-dev cli generate --spec <specification-name> --module billing
You MUST actually run the generator; do not merely describe it or imitate its output. If the AAZ/specification checkout, local source change, credentials, or generator is unavailable, stop and report the blocker instead of editing generated files. Inspect
_aaz_infoprovenance and the complete regenerated diff, then run focusedazdev style,azdev linter, andazdev testvalidation. For an extension, also update its version andHISTORY.rst, preserveazext_metadata.jsoncompatibility, and let release automation updatesrc/index.json.PR title & description format (required)
This repo enforces a PR format (guide). Please author the PR exactly as follows or CI's Check the Format of Pull Request Title and Content will fail.
Use this EXACT PR title (copy verbatim, do not reword):
[Billing] Fix #34082: `az billing product list`: Handle non-ISO product datesKeep the backticks around the command and the
Fix #34082:prefix. You may only adjust the wording after the command (the final summary) if the fix changes; the[Billing]prefix, issue link, and backticked command must stay.Description — follow the PR template and fill in:
- Link the issue — start the Description with a closing keyword so the PR auto-links and closes it:
Fixes #34082. - Related command — the
az ...command this affects. - Description (mandatory) — why the bug happens, what you changed, and the resulting behavior.
- Testing Guide — example command(s) showing the fix works.
- History Notes — leave the title to drive the history note, or add extra lines in the same format (component in brackets + the command in backticks), e.g.
[Billing] `az <command>`: <note>. - Keep the template checklist and tick the items you've satisfied.
- removedRequest X Engineering AgentRequest X Engineering Agent testing and reviewRequest X Engineering Agent testing and review
on Sep 16, 2026 x-engineering-agent commented
on Sep 16, 2026 ContributorMore actionsAutomated processing requires maintainer follow-up for this request.
- addedRequest X Engineering AgentRequest X Engineering Agent testing and reviewRequest X Engineering Agent testing and reviewand removedRequest X Engineering AgentRequest X Engineering Agent testing and reviewRequest X Engineering Agent testing and review
on Sep 19, 2026
This is autogenerated. Please review and update as needed.
Describe the bug
Command Name
az billing product listErrors:
To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.
az billing product list --account-name {} --profile-name {}Expected Behavior
List all the products under the billing account and profile
Environment Summary
Additional Context