Invalid bad_request and exception_thrown events in case of client-error about clj-http-hystrix

[u6f6o]

I also added a PR to fix this behaviour: #14

[joelittlejohn]

Hi @u6f6o. If I understand it correctly, the quote from the Hystrix javadoc is implying that one should not be too broad in applying the HystrixBadRequestException because it means that circuit breaking will rarely happen. Your PR removes circuit breaking behaviour from all client errors (so these are always considered to be normal responses) which also "defeats the purpose of fault-tolerance and fallback behaviour". In the javadoc, the Hystrix team is recommending that you should avoid categorising too many types of error as client errors, so your PR which will avoid categorising 4xx as any kind of error at all (bad request or otherwise) could receive the same criticism I think :)

I understand the problem here though - you consider many 4xx responses as normal and not client errors, so you don't want the statistics to show these as 'bad requests'. I don't think we should force users of this library to treat all 4xx responses as normal errors though.

I see you have updated your PR so that the bad-request-pred can still be used to categories some errors as 'normal' and some as 'exceptional'. Could you reinstate this test:

(fact "errors will cause circuit to break if bad-request-pred is false"

I think it's still valid.

[u6f6o]

Hi @joelittlejohn, Thx for your remarks. I'll have a look at the particular fact. I think you are right; while in my specific case 4xx status codes might be the normal case, it most likely will not be true for all users. Maybe we could think about a solution that could satisfy both scenarios (treat 4xx as success vs. indicate a bad request).

Skimming through the hystrix code a bit, I realised that the HystriBadRequestException is mostly seen as an ignorable exception and thus would not automatically trigger a circuit open. Think I have to check it again :-)

[joelittlejohn]

Although it complicates the docs a bit, I think the only complete solution here (if you want to remove that bad request count from your dashboard) is to offer two predicates. One predicate that identifies all 'failed' requests, and another predicate that can categorise some unsuccessful requests as 'bad request' instead of errors in the service being called.

By default, failure-pred would be (complement http.client/success?) and bad-request-pred would be http.client/client-error?.

In your organisation, you would set failure-pred to http.client/server-error?.

[u6f6o]

Sounds reasonable to me, will try to find time on the weekend.