From 2c01104c3f6c78eaaab07be8598e9ff174536050 Mon Sep 17 00:00:00 2001 From: Igor Nikonov Date: Tue, 23 May 2023 17:30:22 +0000 Subject: [PATCH] Clarification comment on retries controller behavior --- src/Storages/MergeTree/ZooKeeperRetries.h | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/Storages/MergeTree/ZooKeeperRetries.h b/src/Storages/MergeTree/ZooKeeperRetries.h index 7e7d0f08e2c2..e55b04c27b3f 100644 --- a/src/Storages/MergeTree/ZooKeeperRetries.h +++ b/src/Storages/MergeTree/ZooKeeperRetries.h @@ -46,6 +46,16 @@ class ZooKeeperRetriesControl retryLoop(f, []() {}); } + /// retryLoop() executes f() until it succeeds/max_retries is reached/non-retrialable error is encountered + /// + /// the callable f() can provide feedback in terms of errors in two ways: + /// 1. throw KeeperException exception: + /// in such case, retries are done only on hardware keeper errors + /// because non-hardware error codes are semantically not really errors, just a response + /// 2. set an error code in the ZooKeeperRetriesControl object (setUserError/setKeeperError) + /// The idea is that if the caller has some semantics on top of non-hardware keeper errors, + /// then it can provide feedback to retries controller via user errors + /// void retryLoop(auto && f, auto && iteration_cleanup) { while (canTry())