-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Next URL is not attempted if not successful, but exception is not thrown #2735
Comments
Just so I am clear you woud like something like this?
I don't think we need to log it as an error, I think this should be a warning. |
Basically, yes. Maybe it would be good to also have the same log messages that reports that it's trying the next URL, like it does in the catch blocks, for consistency. As far as error vs warning, I'm a little unclear why there would be a null response or a non-OK response that doesn't generate one of the caught exceptions. I observed this happening, but due to the lack of logging, I am not sure what the response looked like. I couldn't reproduce it locally, so I couldn't step through the running code. If you think this is not an error condition, then a warning seems fine. |
So when looking at making these changes, you actually wrote a test that breaks this assumption and verifies that when that status code is not 200 that it does not try the next uri As far as an error or warning, I can see it go both ways. In the case where there is another uri to try it feels like a warning, but if there is no other uri to try it seems like it could be an error. |
That is for the case when the strategy is ConfigClientProperties.MultipleUriStrategy.CONNECTION_TIMEOUT_ONLY, not for strategy=ALWAYS. I think this was a miss on my part. I don't know what sort of HTTP response code would result in this condition or why response would ever be null. If null is returned from this method, IllegalArgumentException (line 178 in ConfigServicePropertySourceLocator.locate(...) method) is eventually thrown, so it doesn't seem like there is some case where this would be a happy path scenario. As such, it seems trying the next URL (when strategy is ALWAYS) would be desirable. Here is kind of what I'm thinking now (starting with the
|
Can you create a PR with your proposed changes so its easier to review? |
I can, but I wasn't planning to do the full merge-ready change. Is this just for preliminary review of the diff of this piece of code without copying/pasting, and then you or one of the main developers would test, polish, finalize, and determine if it has to go in that other related class, also? If you're wanting me to do the whole thing, it will be a couple of days or couple of weeks before I could get to it. |
Describe the bug
See this code in ConfigServicePropertySourceLocator.getRemoteEnvironment method:
We'd like to have this updated so that when this condition is met, it tries the next URL (if any).
We'd also like to have this log the status code at ERROR level when response is not null. And if response is null, log that fact at ERROR level.
Sample
It's difficult to provide a working example. We have a strange situation with our environment that is causing this condition to evaluate to true, but it is related to an Nginx issue, and I would not know how to replicate this in a standalone project.
The text was updated successfully, but these errors were encountered: