-
Notifications
You must be signed in to change notification settings - Fork 209
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Fix "missing error information" error on 409s #4530
Fix "missing error information" error on 409s #4530
Conversation
This can happen if the Azure RP being called returns a JSON error response payload that doesn't match the Azure contract. Instead of overwriting the underlying error, just return it as-is to aid in debugging.
/ok-to-test sha=ca6ddee |
// error shape contract. The good news is that if this happens we know this isn't | ||
// an unregistered RP because that API will have the right shape. We just return | ||
// the resp/err directly in this case to let the caller deal with whatever the problem | ||
// was as we know it wasn't unregistered RP. |
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 don't understand this - it appears to be saying that we know this is a registered RP because those have the right shape, but isn't the problem here due to the result having the wrong shape?
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.
What I'm trying to say is, the error for unregistered RP will have the correct shape. So if we end up in this if (incorrect shape), it had to come from the RP, which means its registered, which means we can just return the error as-is we don't need to try to parse/process it.
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 think one comment needs cleanup, but otherwise this looks good.
This can happen if the Azure RP being called returns a JSON error response payload that doesn't match the Azure contract. Instead of overwriting the underlying error, just return it as-is to aid in debugging.
This can happen if the Azure RP being called returns a JSON error response payload that doesn't match the Azure contract. Instead of overwriting the underlying error, just return it as-is to aid in debugging.