Fix LRO paging should generatebeginListXXXAndWait operation for compatibility-lro: true#3712
Fix LRO paging should generatebeginListXXXAndWait operation for compatibility-lro: true#3712v-jiaodi wants to merge 13 commits intoAzure:mainfrom
beginListXXXAndWait operation for compatibility-lro: true#3712Conversation
Add newline at the end of buildRootIndex.ts
There was a problem hiding this comment.
Pull request overview
Adds a new AppService TypeSpec test scenario configured with compatibility-lro: true to validate LRO + paging codegen behavior (including beginListXXXAndWait generation).
Changes:
- Added
tspconfig.yamlenablingcompatibility-lroand related emitter options for the AppService test. - Added/updated AppService TypeSpec spec files (
main,routes,client, back-compat customizations, and an ASE resource) to drive the scenario. - Introduced additional ARM operations/resources to exercise list/LRO patterns.
Reviewed changes
Copilot reviewed 6 out of 162 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| packages/typespec-test/test/AppService/tspconfig.yaml | Configures the emitter for the AppService test, including compatibility-lro: true. |
| packages/typespec-test/test/AppService/spec/routes.tsp | Adds many ARM operations (including @list operations) to exercise paging/LRO behavior. |
| packages/typespec-test/test/AppService/spec/main.tsp | Defines the service namespace, versions, and legacy Operations interface for the test scenario. |
| packages/typespec-test/test/AppService/spec/client.tsp | Adds client-generator customizations and a couple of customized operations for the scenario. |
| packages/typespec-test/test/AppService/spec/back-compatible.tsp | Adds legacy/back-compat flattening + naming directives used by generated clients. |
| packages/typespec-test/test/AppService/spec/AppServiceEnvironmentResource.tsp | Defines an ARM resource and async actions returning collections to exercise LRO/paging generation. |
| @summary("Validate whether a resource can be moved.") | ||
| @summary("Validate whether a resource can be moved.") |
There was a problem hiding this comment.
These operations have duplicate @summary decorators with identical text. Keeping only one @summary per operation will avoid duplicated documentation output and reduce noise.
| @summary("Validate if a resource can be created.") | ||
| @summary("Validate if a resource can be created.") |
There was a problem hiding this comment.
These operations have duplicate @summary decorators with identical text. Keeping only one @summary per operation will avoid duplicated documentation output and reduce noise.
| import "@azure-tools/typespec-azure-resource-manager"; | ||
| import "@azure-tools/typespec-client-generator-core"; | ||
|
|
||
| using Http; |
There was a problem hiding this comment.
Http is not a standard namespace alias; elsewhere in this test set you use TypeSpec.Http. This is likely to fail TypeSpec compilation unless some imported library explicitly defines a top-level Http namespace. Prefer using TypeSpec.Http; (and ensure the corresponding import is present/available via dependencies).
| using Http; | |
| using TypeSpec.Http; |
| name: string; | ||
| }, | ||
| ResourceRoute = #{ | ||
| route: "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/microsoft.Web/hostingEnvironments", |
There was a problem hiding this comment.
The provider namespace in the route uses microsoft.Web (lowercase m), while the canonical ARM provider name and the rest of the spec uses Microsoft.Web. Use consistent casing (Microsoft.Web) to prevent mismatches in generated routes/operation IDs and to align with ARM conventions.
| route: "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/microsoft.Web/hostingEnvironments", | |
| route: "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/hostingEnvironments", |
fixes #3707