ui: Enable blocking queries by default #6194
Conversation
| @@ -65,7 +65,7 @@ const createProxy = function(repo, find, settings, cache, serialize = JSON.strin | |||
| key: key, | |||
| type: BlockingEventSource, | |||
| settings: { | |||
| enabled: settings.blocking, | |||
| enabled: typeof settings.blocking === 'undefined' || settings.blocking, | |||
There was a problem hiding this comment.
If settings.block is undefined / not set, this would enable it, otherwise if it's set to something it'll respect that setting, which makes sense.
| @@ -5,11 +5,6 @@ Feature: dc / list-blocking | |||
| I want to see changes if I change consul externally | |||
| Background: | |||
| Given 1 datacenter model with the value "dc-1" | |||
| And settings from yaml | |||
There was a problem hiding this comment.
This is the removal of the previous setting and the blocking test which should now pass with the default, I think.
There was a problem hiding this comment.
Yup exactly, I think there 'might' be a few other places in the tests where I specifically set it to on before running the tests, that will now essentially be a no-op now. I don't mind those still being in there though, I just removed this one to make sure it definitely works when you haven't set anything to on.
Since we've now turned on blocking queries by default this means that a second GET request is made after the PUT request that we are asserting for but before the assertion itself, this meant the assertion failed. We double checked this by turning off blocking queries for this test using ``` And settings from yaml --- consul:client: blocking: 0 --- ``` which made the test pass again. As moving forwards blocking queries will be on by default, we didn't want to disable blocking queries for this test, so we now assert the last PUT request specifically. This means we continue to assert that the session has been destroyed but means we don't get into problems of ordering of requests here
|
I noticed a test not passing here, and looked into it, there's more info in the last commit here, but will repeat here for reference/ease. Since we've now turned on blocking queries by default this means that a And settings from yaml
---
consul:client:
blocking: 0
---which made the test pass again. As, moving forwards, blocking queries will be on by default, we didn't |
-Enable blocking queries by default -Change assertion to check for the last PUT request, not just any request for session destruction from a node page. Since we've now turned on blocking queries by default this means that a second GET request is made after the PUT request that we are asserting for but before the assertion itself, this meant the assertion failed. We double checked this by turning off blocking queries for this test using ``` And settings from yaml --- consul:client: blocking: 0 --- ``` which made the test pass again. As moving forwards blocking queries will be on by default, we didn't want to disable blocking queries for this test, so we now assert the last PUT request specifically. This means we continue to assert that the session has been destroyed but means we don't get into problems of ordering of requests here
-Enable blocking queries by default -Change assertion to check for the last PUT request, not just any request for session destruction from a node page. Since we've now turned on blocking queries by default this means that a second GET request is made after the PUT request that we are asserting for but before the assertion itself, this meant the assertion failed. We double checked this by turning off blocking queries for this test using ``` And settings from yaml --- consul:client: blocking: 0 --- ``` which made the test pass again. As moving forwards blocking queries will be on by default, we didn't want to disable blocking queries for this test, so we now assert the last PUT request specifically. This means we continue to assert that the session has been destroyed but means we don't get into problems of ordering of requests here
-Enable blocking queries by default -Change assertion to check for the last PUT request, not just any request for session destruction from a node page. Since we've now turned on blocking queries by default this means that a second GET request is made after the PUT request that we are asserting for but before the assertion itself, this meant the assertion failed. We double checked this by turning off blocking queries for this test using ``` And settings from yaml --- consul:client: blocking: 0 --- ``` which made the test pass again. As moving forwards blocking queries will be on by default, we didn't want to disable blocking queries for this test, so we now assert the last PUT request specifically. This means we continue to assert that the session has been destroyed but means we don't get into problems of ordering of requests here
This enables blocking queries by default. They can still be turned off via the settings page, and if anyone has turned off blocking queries in previous versions of the UI and have that preference stored in localStorage still, it will continue to respect that setting.