ui: Ensure routing tab is always shown when connect enabled #8209
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
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
type/bug
|
🍒✅ Cherry pick of commit 07b49f8 onto |
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 we can only tell if connect is disabled on a datacenter by detecting a 500 error from a connect related endpoint.
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.
In the above PR (present in Consul 1.8.0) we mistakenly
returned from a catch instead of rethrowing the error, which meant that when a500error was caught, the discovery chain data would be removed. Whilst at first glance this doesn't seem like a big problem due to the endpoint erroring, but we also receive a0status errors when we abort endpoints during blocking queries. This means that in certain cases we can replace cached data for the discovery chain withundefinedwhich will not get replaced until the blocking query responds again. From a user perspective, this can result in the Routing tab being hidden in certain situations.This PR replaces the
returnwith athrow, which means that other errors are dealt with correctly via the blocking query error detection/logic.In the meantime, a page refresh will bring back the routing tab and visualisation when it has been removed.