ui: Reduce discovery-chain log errors #8065
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently the only way that the UI can know whether connect is enabled or not is whether we get 500 errors from certain endpoints. One of these endpoints we already use, so aswell as recovering from a 500 error, we also remember that connect is disabled for the rest of the page 'session' (so until the page is refreshed), and make no further http requests to the endpoint. This means that log spam is reduced to only 1 log per page refresh instead of 1 log per service navigation. Longer term we'll need some way to dynamically discover whether connect is enabled per datacenter without relying on something that will add error logs to consul.
johncowen
changed the title
johncowen
pushed a commit
that referenced
this pull request
Jun 30, 2020
In #8065 we attempted to reduce the amount of times that the UI requests the discovery chain endpoint when connect is disabled on a datacenter. Currently we can only tell if connect is disabled on a datacenter by detecting a 500 error from a connect related endpoint. In the above PR we mistakenly returned from a catch instead of rethrowing the error, which meant that when a none 500 error was caught the discovery chain data would be removed. Whilst at first glance this doens't seem like a big problem due to the endpoint erroring, but we also receive a 0 error when we abort endpoints during blocking queries. This means that in certain cases we can remove cached data for the discovery chain and then delay reloading it via a blocking query. This PR replaces the return with a throw, which means that everything is dealt with correctly via the blocking query error detection/logic.
johncowen
added a commit
that referenced
this pull request
Jul 1, 2020
In #8065 we attempted to reduce the amount of times that the UI requests the discovery chain endpoint when connect is disabled on a datacenter. Currently we can only tell if connect is disabled on a datacenter by detecting a 500 error from a connect related endpoint. In the above PR we mistakenly returned from a catch instead of rethrowing the error, which meant that when a none 500 error was caught the discovery chain data would be removed. Whilst at first glance this doens't seem like a big problem due to the endpoint erroring, but we also receive a 0 error when we abort endpoints during blocking queries. This means that in certain cases we can remove cached data for the discovery chain and then delay reloading it via a blocking query. This PR replaces the return with a throw, which means that everything is dealt with correctly via the blocking query error detection/logic.
hashicorp-ci
pushed a commit
that referenced
this pull request
Jul 1, 2020
In #8065 we attempted to reduce the amount of times that the UI requests the discovery chain endpoint when connect is disabled on a datacenter. Currently we can only tell if connect is disabled on a datacenter by detecting a 500 error from a connect related endpoint. In the above PR we mistakenly returned from a catch instead of rethrowing the error, which meant that when a none 500 error was caught the discovery chain data would be removed. Whilst at first glance this doens't seem like a big problem due to the endpoint erroring, but we also receive a 0 error when we abort endpoints during blocking queries. This means that in certain cases we can remove cached data for the discovery chain and then delay reloading it via a blocking query. This PR replaces the return with a throw, which means that everything is dealt with correctly via the blocking query error detection/logic.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently the only way that the UI can know whether connect is enabled
or not is whether we get 500 errors from certain endpoints.
One of these endpoints we already use, so aswell as recovering from a
500 error, we also remember that connect is disabled for the rest of the
page 'session' (so until the page is refreshed), and make no further
http requests to the endpoint for that specific datacenter.
This means that log spam is reduced to only 1 log per page refresh/dc
instead of 1 log per service navigation.
Longer term we'll need some way to dynamically discover whether connect
is enabled per datacenter without relying on something that will add
error logs to consul.
Partly addresses #8033