We want to configure our clients with two URLs for two config servers - each one pointing to a different git management server. If one git management server goes down, the client should receive an error then try the second URL. However, the conditions for retry are too limited for our needs:

  1. The main issue is that if git server can not be reached, config server returns 404. (404 seems inappropriate, because it is not a client error. However, I would guess changing it now would not be feasible considering it changes existing behavior.) When 404 is received, the client does not try the second URL. It makes sense not to do a retry for a 4XX error conceptually, since they should be client errors. However, git server not being reached is not a client issue, and we want the client to try the next URL in that case.

  2. Another issue is with 500 errors. The documentation states, "if the Config Server returns a 500 (Internal Server Error) response...the Config Client does not try to fetch properties from other URLs". However, 500 is a server-side error, not client error. Although this is not our main concern, it seems best to have client try next URL. (Perhaps the first URL points to a config server with a defect, but second URL points to a newer or older one without the defect, so trying the other one could be beneficial.)

Proposed Solution Allow for configuring a list of HTTP response code and/or response code series for which client will try the next URL in the list. The current behavior could remain as default behavior.

Note: Another reason for 404 is if client passes bad label. For us, this is usually only in non-prod environments. I'd rather have the client try next URL when it's a bad label (although unlikely to change the response), than to not retry when the 404 is due to git server being down.

Comment From: marnee01

A simpler solution would be a single flag to enable trying multiple URLs on any error response, even though it would mean trying when the issue is clearly a client-side error. So:

Default/current behavior: Only try the next URL in the list if ResourceAccessException is caught. New behavior: If property XYZ is set to true, then also try the next URL if HttpClientErrorException is caught.

Note that the code is in the ConfigServicePropertySourceLocator.getRemoteEnvironment(...) method.

Comment From: marnee01

This is very important to us. If I can get approval to spend the time, I may try to implement this and push the change to the project. However, it would need to get pushed back to spring-cloud-config-client 2.1, I believe. Most of our services are still at spring boot 2.1 and won't be upgraded any time soon. (Our upgrade steps not trivial.)

I've never done this before. How feasible would it be for me to patch it back to previous versions or to have you do the same with my change to the latest?

Comment From: reboot-armani

@marnee01 has this been merged to the latest config client version? or version can I find it in?

Comment From: marnee01

@reboot-armani

@marnee01 has this been merged to the latest config client version? or version can I find it in?

No, the spring team has not approved it, so it's not been merged. It looks like they marked it for team discussion just today.