`format: arm-id` metadata getting lost during processing pipeline
See original GitHub issueBefore filling a bug
- have you checked the faq for known issues.
- have you checked existing issues
Describe the bug
Using @autorest/core
version 3.9.1 and @autorest/modelerfour
version 4.24.1, the string format of arm-id
and the x-ms-arm-id-details
extensions seem to be getting inconsistently dropped somewhere along the processing pipeline. When processing the ManagedClusterAgentPoolProfileProperties
shape in version 2022-06-01 of the containerservice
resource manager spec in a custom plugin at the end of the processing pipeline, I expected to see vnetSubnetID
, podSubnetID
, nodePublicIPPrefixID
, proximityPlacementGroupID
, and hostGroupID
use an instance of ArmIdSchema
as their schemas, but the lattermost used an instance of Aspect
(with the x-ms-arm-id-details
extension data present in the schema) and the rest used an instance of StringSchema
(with no format
or x-ms-arm-id-details
extension data present in the schema).
Using @autorest/core
version 3.9.1 and @autorest/modelerfour
version 4.24.1, plugins downstream on the processing pipeline from modelerfour do not see instances of ArmIdSchema
used. Instead, the schema will be an instance of Aspect
with a type of arm-id
.
Autorest command used:
autorest --use=@autorest/modelerfour --use=/home/jeskew/Workspaces/bicep-types-az/src/autorest.bicep --bicep --output-folder=/tmp/_bcp_1660150886081/containerservice --level=verbose --multiapi --title=none --skip-semantics-validation /home/jeskew/Workspaces/azure-rest-api-specs/specification/containerservice/resource-manager/readme.md --level=verbose --bicep.debugger
Additional context
I put a few debugger
statements in the modelerfour extension and saw that hostGroupID
’s was being correctly represented as an instance of ArmIdSchema
, so the conversion to Aspect
is probably happening either where data is being returned to autorest from the plugin process or where data is being provided to my custom plugin. The plugin uses autorest
version 3.6.2, @autorest/codemodel
version 4.19.1, and @autorest/extension-base
version 3.5.0.
All other properties of ManagedClusterAgentPoolProfileProperties
that I was expecting to be ARM IDs had already shed their format
and x-ms-arm-id-details
schema properties, presumably in a plugin placed before modelerfour in the processing pipeline.
Issue Analytics
- State:
- Created a year ago
- Comments:6 (4 by maintainers)
Top GitHub Comments
Everything is working correctly using the version of modelerfour from the linked PR. Thanks for the quick work on this!
Thanks for the investigation @jeskew, I have a PR with the fix here, could you just confirm this works fine following the instruction here https://github.com/Azure/autorest/pull/4616. Guessing it must as this is the change you probably did locally to make it work.