iron_bank
iron_bank copied to clipboard
Fetch error class using faultcode instead of body text matching
Description
This is GitLab's attempt to fix #79: some custom fields can contain error codes. They are mistakenly treated as actual error.
Some error response hash now contains "faultcode", for example the body could be:
{
"detail" => {
"MalformedQueryFault" => {
"FaultMessage" => "invalid field for query: Account.foo",
"FaultCode" => "INVALID_FIELD" }
},
"faultcode" => "fns:INVALID_FIELD",
"faultstring" => "invalid field for query: Account.foo"
}
So when response is a hash, we try to find faultcode to lookup error class instead of body text matching.
Body text matching is bad because it can cause false positives, when data happens to contain error code in the custom fields.
Notes
Bulk operation (which returns a hash) is the exception. We assume it does not contain custom fields info based on experience.
Tasks
- [ ] TODO item before it can be reviewed and/or merged
- [ ] Another TODO item
Risks
We don't know originally when we implemented from_body
, how does the typical response body looks like (the spec does not provide any believable example). We also suspect that it might have changed since (and possibly making it obsolete).
If we have more concrete examples, we should be more confident on whether this breaks/fixes things.
Hi @rringler would you still have the example response / use case from the past?