`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 Related StackOverflow Question
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.