Describe the bug When trying to load a configuration file that references the configuration server itself, like this:
https://github.com/kevindeyne-ab/sample-config-repo/blob/fec316d2c010a28999eb91440a214613a8a0eece/bug/application-dev.yml#L4C1-L12C22
The config server will get busy (infinitely?) trying to load the config. This also stops other configurations from being server.
I do not think this kind of a configuration necessarily makes logical sense, but this scenario could happen realistically when a developer tries to move from an internal application.yml to a server based one, without removing the bootstrapping part. What caught me by surprise when it happened for us was that this killed the server from functioning as soon as the buggy config was touched, instead of throwing an error.
(in the above example, presuming the server is being run on localhost:8080)
This is applicable to spring-cloud-config-server 3.5.4.
Sample Here is a minimally reproducible scenario: https://github.com/kevindeyne-ab/selfref-config-server
- Checkout this repo
- mvn spring-boot:run
- Go to http://localhost:8080/works/dev and see the config server works and serves some configuration
- Go to http://localhost:8080/bug/dev and see it load forever
- Go to http://localhost:8080/works/dev and see that this is impacted as well
Comment From: ryanjbaxter
Outside of saying this configuration is invalid, I am not sure what we can do to prevent this. This configuration creates a circular dependency which results in a deadlock in the config server. We want to allow spring.config.import statements in remote configuration files in order to import other configuration and the only way to solve this would be to not allow this.
Comment From: spring-cloud-issues
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Comment From: kevindeyne-ab
The lock is throwing me off the most. I can totally understand that the individual wrong config cannot load, but it in turn causing every other config to stop loading (until, presumably, it times out) is kind of scary. In our scenario, a single developer's mistake ended up keeping an entire server offline for a few hours until we found the culprit - blocking local testing.
I would imagine there'd be two paths to potentially help with this: 1) As you say, perhaps the ability to just turn off remote configs optionally would be an effective way to safeguard us from this. Obviously the default behavior could remain what it is. 2) I saw the place where it got stuck was the combination of the RestTemplate call waiting until timeout + the lock preventing anything else from processing during that time. Is it possible to change how quickly that timeout happens through a config, perhaps? I believe it defaults to 3 minutes or so now.
Comment From: ryanjbaxter
- This would most likely require some changes in Spring Boot, but we will have to investigate.
- You can customize
RestTemplate. See https://docs.spring.io/spring-cloud-config/reference/client.html#providing-a-custom-resttemplate-using-config-data
Comment From: spring-cloud-issues
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Comment From: spring-cloud-issues
Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.