Custom ErrorDecoder and RetryableExceptions

[Kidlike]

I have set up a custom ErrorDecoder which is used for all 4xx responses, but for example if the inbound server is down, my custom ErrorDecoder is never used, and instead just a RetryableException is thrown.

Is there something else I could override that will control what exception is thrown regardless of the scenario ?

Also something like this would help to create better logs... Now the logs are inconsistent because of this conditionality.

[kdavisk6]

I suspect that the Client instance you have configured is set up to automatically retry connection based exceptions. Do you have an example of the Builder configuration you used?

[Kidlike]

Sorry forgot to mention I use org.springframework.cloud.netflix.feign.FeignClient:

@FeignClient(name = "filerepo", url = "${filerepo.host}")

[kdavisk6]

That is a special Spring version of an auto-configured Feign client. Have you asked your question with the Spring Cloud folks? There are too many variables there for me to help you out. For example, you can manually configure a Client, or used the default one that Spring gives you, which is based on a number of different scenarios.

I suggest that you check with them first and see if there is something you can audit or update in your Spring configuration first.

[Kidlike]

Thanks, I will investigate from the Spring side of things :)

[Squiry]

@kdavisk6 It's the issue with default SynchronousMethodHandler, not with Spring Cloud.
SynchronousMethodHandler invokes ErrorDecoder in case of http response only. If there's no http response (IOException thrown by Client) then it wrappes exception with RetryableException and throws it. code

[Kidlike]

@Squiry Nice catch :)

Any suggestions?

[Squiry]

Well ErrorDecoder should decode erros and there's nothing to decode anyway.
You can proxy Client and handle IOException there if you really need it. Or you can just handle RetryableException.

[Kidlike]

Yeah at the moment I'm just handling RetryableException. I guess I'll stay like this. Thanks though !

[kdavisk6]

The current implementation treats all IOExceptions from the Client as something related to the communication and should be retried. This will continue for the maxAttempts and then throw the RetryableException out, if you use the default Retryer. If this is not the behavior you want, you can implement your own Retryer and process them accordingly.

[kdavisk6]

Closing based on the last comment.

[shavkat1121]

thanks