-
Notifications
You must be signed in to change notification settings - Fork 15
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
fix(151): clarify protobuf response for no parallel requests #228
base: main
Are you sure you want to change the base?
Conversation
For protobuf guidance, it was unclear response code should be.
@wora addressed comments! PTAL. |
LGTM. I think splitting into tabs per protocol is the right answer. I'm not a reviewer, so cannot approve. |
|
||
{% tab proto %} | ||
|
||
- A resource that does not support concurrent mutation requests **must** return an | ||
`ABORTED` error if the resource has an outstanding mutation. | ||
|
||
{% tab oas %} | ||
|
||
- A resource that does not support concurrent mutation requests **must** respond | ||
with a `409 Conflict` status code if the resource has an outstanding mutation. | ||
|
||
{% endtabs %} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
{% tab proto %} | |
- A resource that does not support concurrent mutation requests **must** return an | |
`ABORTED` error if the resource has an outstanding mutation. | |
{% tab oas %} | |
- A resource that does not support concurrent mutation requests **must** respond | |
with a `409 Conflict` status code if the resource has an outstanding mutation. | |
{% endtabs %} | |
- Resource that does not permit multiple requests in parallel (denying any new | |
request until the one that is in progress finishes) **must** return | |
`ABORTED`/`409 Conflict` if a user attempts a parallel request, and include an error | |
message explaining the situation. |
We discussed this live - seems unfortunate to add all the tab chrome to the page just to vary a single term. Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with consolidating it.
@wora gave feedback on the "include an error message" guidance earlier, and suggested that adding this type of guidance may result in users using the error string as a way to figure out the actual error (concurrent request). I removed that part intentionally based on that feedback (as I also agreed). Thoughts on that?
For protobuf guidance, it was unclear response code should be.
Partially addresses #224
🍱 Types of changes
What types of changes does your code introduce to AEP? Put an
x
in the boxesthat apply
📋 Your checklist for this pull request
Please review the AEP Style and Guidance for
contributing to this repository.
General
references AEPs
correctly.
(usually
prettier -w .
)