-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
.NET DPG LRO is making an extra GET call to the resource URI, breaking documented response schema #29347
Comments
Label prediction was below confidence level |
FWIW, I tagged the reference commit from my fork to keep this living as long as my fork does. |
Investigating if Python's IMO, if an @kristapratico did have a good idea for a workaround, though: since we're already transforming the swagger for autorest to provide the schema for the final object, we could update the resource @tg-msft @mikekistler what are your thoughts here? |
Talking offline, we'll do @kristapratico's idea for the CLU 1.0 GA:
@annelo-msft I'll leave it up to you whether you want to keep this issue as a tracking issue for support of this (anti?) pattern. |
Based on investigations by @AlexanderSher, @kristapratico, and @lmazuel (thank you all!), we believe the .NET implementation is the same as Python's implementation and is correct. We make the final GET request because the original request was a PUT, as implemented here: https://github.com/Azure/autorest.csharp/blob/feature/v3/src/assets/Generator.Shared/NextLinkOperationImplementation.cs#L196 Per @lmazuel:
Since the .NET implementation is correct, we will not make changes to the generator or shared source types. |
For Sample5_ImportProject.cs in PR #29340, the
ImportProject
andTrain
LROs are working as expected based on the session file, but theDeployProject
has an extraGET
and I can't tell where it's coming from. Specifically, the initial LRO request indeed returns a 202 with anOperation-Location
to a status monitor:The next several requests are what you'd expect -
status
isrunning
- until the final status update:But then immediately afterward, there's this extra GET which is what the
Operation<BinaryData>.Value
ultimately contains:I can't tell from where this comes? Why is the LRO querying the actual resource? The generated LRO implementation uses
OperationFinalStateVia.Location
just like the other aforementioned LROs:@annelo-msft @AlexanderSher @chunyu3 ?
/cc @kristapratico @mshaban-msft @tg-msft @johanste
Some useful links:
DeployProject
LRO: https://github.com/Azure/azure-rest-api-specs/blob/725f4ca360426a32d20e81eb945065e62c285d6a/specification/cognitiveservices/data-plane/Language/stable/2022-05-01/analyzeconversations-authoring.json#L532-L540DeployProject
status monitor: https://github.com/Azure/azure-rest-api-specs/blob/725f4ca360426a32d20e81eb945065e62c285d6a/specification/cognitiveservices/data-plane/Language/stable/2022-05-01/analyzeconversations-authoring.json#L619-L624DeployProject
resource GET: https://github.com/Azure/azure-rest-api-specs/blob/725f4ca360426a32d20e81eb945065e62c285d6a/specification/cognitiveservices/data-plane/Language/stable/2022-05-01/analyzeconversations-authoring.json#L483-L488Originally posted by @heaths in #29331 (comment)
The text was updated successfully, but these errors were encountered: