[PostResponseCodes] LRO POST Responses checks are broken

Open
#809 2 comments 0 reactions 1 assignee View on GitHub

@AkhilaIlla is already working on this.

Since Jan 21, 2026.

Assessment

This issue has not been assessed yet.

Description

This PR made two changes that regress how LRO POST operations are supposed to work: https://github.com/Azure/azure-openapi-validator/pull/784/files

First, the POST operation itself only actually returns a 202 or an error response. Any 200 or 204 response is the result of subsequent polling using GET requests of the uri in location or other headers. This is consistent with the RPC, which describes the 200 or 204 response after subsequent requests.

Second, we used to add a "fake" 200 response for LRO POST with a schema or a "fake" 204 responses for LRO POST without a schema, so that clients understood what the eventual response would be after polling.

A few years ago, we stopped requiring the "fake" 204 response for responses without a schema, because all consumers of swagger understood the lack of a 200 response to mean a void response after polling.

We also started supporting x-ms-long-running-operation-options.final-state-schema to indicate the final state schema, with its absence indicating a void response as an alternative to these fake responses.

It is entirely safe to require either a 200 response or a final-state-schema for lro POST operations that return a non-void result.

It is also entirely safe to require just a 202 for lro POST operations with a void result.

This is what the rule should check for.

This is currently breaking TypeSpec POST LROs, which were specifically changed to accommodate the 202-only for POST operations when this rule was changed a few years ago.

At the very least, there needs to be discussion about these rule changes with the TypeSpec team before we create new violations.

Dominant language
TypeScript
Stars
53
Forks
57
Avg merge
1d 23h
Merged PRs (30d)
2

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Azure/azure-openapi-validator

All issues in Azure/azure-openapi-validator

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.