README.md in knapsack_pro-0.20.0 vs README.md in knapsack_pro-0.21.0

- old
+ new

@@ -147,14 +147,14 @@
 
 ```ruby
 # spec/spec_helper.rb or wherever is your VCR configuration
 
 VCR.configure do |config|
-  config.ignore_hosts 'localhost', '127.0.0.1', '0.0.0.0', 'api.knapsackpro.com'
+  config.ignore_hosts('localhost', '127.0.0.1', '0.0.0.0', 'api.knapsackpro.com')
 end
 
-WebMock.disable_net_connect!(:allow => 'api.knapsackpro.com') if defined?(WebMock)
+WebMock.disable_net_connect!(:allow => ['api.knapsackpro.com']) if defined?(WebMock)
 ```
 
 ### Usage (How to set up 1 of 3)
 
 __Tip:__ You can find here example of rails app with already configured knapsack_pro.
@@ -310,11 +310,18 @@
 Note if you will run queue mode command for the first time it might be slower.
 The second build should have better optimal test suite split.
 
 ### Additional info about queue mode
 
-If you are not using one of supported CI providers then please note that knapsack_pro gem doesn't know what is CI build ID in order to generated queue for particular CI build. This may result in two different CI builds taking tests from the same queue when CI builds are running at the same time against the same git commit.
-To avoid this you can specify unique `KNAPSACK_PRO_CI_NODE_BUILD_ID` environment variable for each CI build. This mean that each CI node that is part of particular CI build should have the same value for `KNAPSACK_PRO_CI_NODE_BUILD_ID`.
+* If you are not using one of [supported CI providers](#supported-ci-providers) then please note that knapsack_pro gem doesn't know what is CI build ID in order to generated queue for particular CI build. This may result in two different CI builds taking tests from the same queue when CI builds are running at the same time against the same git commit.
+
+  To avoid this you can specify unique `KNAPSACK_PRO_CI_NODE_BUILD_ID` environment variable for each CI build. This mean that each CI node that is part of particular CI build should have the same value for `KNAPSACK_PRO_CI_NODE_BUILD_ID`.
+
+* Note that in the queue mode you cannot retry the failed CI node with exactly the same subset of tests that were run on the CI node in the first place. It's possible only in regular mode ([read more](#knapsack_pro_fixed_test_suite_splite-test-suite-split-based-on-seed)).
+
+  Let's say one of the CI nodes failed and you retry just this single CI node while other CI nodes are still running. The retried CI node will be connected to the queue consumed by running CI nodes.
+
+  In the case when there are no running CI nodes then your retried CI node will initialize a new queue and it will run whole test suite from the queue because there will be no other CI nodes running connected to the queue. The order of tests on retried CI node will be different than on the first run.
 
 ### Supported test runners in queue mode
 
 At this moment the queue mode works for:
 