Describe the bug
Adding/changing a key triggers refreshing values for Environment and @Value. But deleting a key does not. This is a strange behavior. e.g., you have two paths to watch in Consul: /default/config and /my-service/config, if I add a key to my-service/config I can override the default settings in /default/config, but when I delete the key, nothing happens and I have to restart my app.
Moreover, when I delete a key, in ConfigWatch.watchConfigKeyValues(), the index will stop increasing. Suppose you get an index 16866 previously, then for the deletion event we should increase the current index to the new index in the response, maybe 16914. Currently the watch just stops at 16866 and retry and retry over again. If you set timeout shorter to 3 second you will see this busy loop behavior from log. Without increasing the index, it's a little less efficient and we will waste some resources.
I think the problem is, when 404 with a higher index is returned, it means the key was deleted, and we should publish the RefreshEvent and increase the index. Then the spring config framework should listen to the event and change accordingly, maybe delete the key from ConsulPropertySource.
spencergibb
commented
1 year ago
Describe the bug Adding/changing a key triggers refreshing values for Environment and @Value. But deleting a key does not. This is a strange behavior. e.g., you have two paths to watch in Consul: /default/config and /my-service/config, if I add a key to my-service/config I can override the default settings in /default/config, but when I delete the key, nothing happens and I have to restart my app.
Moreover, when I delete a key, in ConfigWatch.watchConfigKeyValues(), the index will stop increasing. Suppose you get an index 16866 previously, then for the deletion event we should increase the current index to the new index in the response, maybe 16914. Currently the watch just stops at 16866 and retry and retry over again. If you set timeout shorter to 3 second you will see this busy loop behavior from log. Without increasing the index, it's a little less efficient and we will waste some resources.
I think the problem is, when 404 with a higher index is returned, it means the key was deleted, and we should publish the RefreshEvent and increase the index. Then the spring config framework should listen to the event and change accordingly, maybe delete the key from ConsulPropertySource.
Sample N/A
PR: https://github.com/spring-cloud/spring-cloud-consul/pull/781