-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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(dbless): drain error table when flattening errors #10256
Conversation
@RobSerafini This is a fix, but it's not really a blocker for anyone, so feel free to remove from the 3.2 milestone if we're too strapped for time. |
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.
No concern from our side. We aren't using fields
at all (with or without the availability of flattened errors--we do use messages
for logging though), and I agree that if you've opted into flattened that you shouldn't need the old format also.
@tyler-ball - I leave it to you to decide the milestone question. |
This will need to wait; removed from milestone. |
|
This only affect `POST /config?flatten_errors=1`. When nested errors are flattened for the response body, they should be removed from the original error table so that they are not included in the final `fields` error object. Errors that are not flattened should remain. It could be argued that this is a backwards-incompatible change, but: 1. This is opt-in only via the `flatten_errors` query param. 2. It's arguably a behavioral fix since we are effectively de-duplicating the errors in the response. 3. This makes the response object much, much cleaner.
fd9a6b0
to
66ff8a0
Compare
66ff8a0
to
1763c7e
Compare
Changelog entry was added, and I've just rebased on master. This is good to go once CI is 🟢. |
* fix(dbless): drain error table when flattening errors This only affect `POST /config?flatten_errors=1`. When nested errors are flattened for the response body, they should be removed from the original error table so that they are not included in the final `fields` error object. Errors that are not flattened should remain. It could be argued that this is a backwards-incompatible change, but: 1. This is opt-in only via the `flatten_errors` query param. 2. It's arguably a behavioral fix since we are effectively de-duplicating the errors in the response. 3. This makes the response object much, much cleaner. * docs(changelog): update for #10256 (cherry picked from commit c550c11)
* fix(dbless): drain error table when flattening errors This only affect `POST /config?flatten_errors=1`. When nested errors are flattened for the response body, they should be removed from the original error table so that they are not included in the final `fields` error object. Errors that are not flattened should remain. It could be argued that this is a backwards-incompatible change, but: 1. This is opt-in only via the `flatten_errors` query param. 2. It's arguably a behavioral fix since we are effectively de-duplicating the errors in the response. 3. This makes the response object much, much cleaner. * docs(changelog): update for #10256 (cherry picked from commit c550c11) Co-authored-by: Michael Martin <[email protected]>
Does this need an explicit cherry pick from CE to EE? |
This only affect
POST /config?flatten_errors=1
.When nested errors are flattened for the response body, they should be removed from the original error table so that they are not included in the final
fields
error object. Errors that are not flattened should remain.It could be argued that this is a backwards-incompatible change, but:
flatten_errors
query param.flatten_errors
is a new, yet unreleased feature, there is no defined behavior to be broken.fields
object has not changed.