-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Property added denoted in CommonTypes.v4 didn't get parsed in model using CommonTypes.v5 #1992
Comments
I tried with OpenAPI3 emitter and it correctly filtered out the Playground links: |
I haven't been able to get the emitter to actually emit anything except an empty array following the instructions (I am using wsl if that matters), so can't dig too deeply. Since the In the openapi3 emitter, we get the projected service: const document = await getOpenApiFromVersion(
projectedServiceNs === projectedProgram.getGlobalNamespaceType()
? { type: projectedProgram.getGlobalNamespaceType() }
: getService(program, projectedServiceNs)!,
record.version,
); and then pass that service directly into const httpService = ignoreDiagnostics(getHttpService(program, service.type)); In your emitter, it looks like you store the original service: const aazContext: AAZEmitterContext = {
program: projectedProgram,
service: service,
sdkContext: sdkContext,
apiVersion: apiVersion,
tracer,
}; Though, that service isn't actually used. You do however call const services = ignoreDiagnostics(getAllHttpServices(context.program)); You are using the projectProgram when making that call, but I wonder if you'd have better results passing in the projected service directly. Again - I'd give it a try but I can't get your repro steps to emit anything locally :-( |
Yes I was thinking maybe we didn't use the proper function for parsing models from commonTypes or missed the version somewhere. However, for inline model properties from target tsp file, the versioning part can be taken care of by the compiler by default, only commonTypes properties has this kind of versioning lost issue. As @allenjzhang and @chrisradek mentioned, will try the one from |
During my development period, there often occurs to me that, is there a dev doc or function specification that emitter developer can use when they try to fetch and parse different parts of different models. |
Describe the bug
The target tsp is from MongoCluster: https://github.com/Azure/azure-rest-api-specs/blob/main/specification/mongocluster/DocumentDB.MongoCluster.Management/main.tsp#L23
When we try to access the properties from metadata of @typespec/http, we cannot find the property
groupId
added in v4, while this mongoCluster is using commonTypes.v5.The lost property is
groupId
here:typespec-azure/packages/typespec-azure-resource-manager/lib/common-types/private-links.tsp
Lines 61 to 62 in 79f047c
Reproduction
Our emitter is
typespec-aaz
here: https://github.com/Azure/aaz-dev-tools/tree/dev/src/typespec-aazPlease clone the emitter above, link it to local npm env and then provide the tspconfig.yaml as following:
And then, run
tsp compile ${your_workspaceFolder}/specification/mongocluster/DocumentDB.MongoCluster.Management/main.tsp -- config yourconfig.yaml
and check the output file./tsp-output/@azure-tools/typespec-aaz/resources_operations.json
.we can check
properties
ofprivateEndpointConnections
and you'll findprivateEndpoint
,privateLinkServiceConnectionState
and other stuff, exceptgroupIds
.Emitter code line for parsing properties of common types
PrivateEndpointConnectionProperties
is here: https://github.com/Azure/aaz-dev-tools/blob/dev/src/typespec-aaz/src/convertor.ts#L655. We use metadata from@typespec/http
and check all its properties for our aaz model generation.Checklist
The text was updated successfully, but these errors were encountered: