Fixed potential data loss in case of ZK errors [#CLICKHOUSE-3916] #2939
Conversation
| /** If the connection is lost, and we do not know if the changes were applied, we can not delete the local part | ||
| * if the changes were applied, the inserted block appeared in `/blocks/`, and it can not be inserted again. | ||
| * | ||
| * NOTE that in contrast to original libzookeeper, in our library we may also get ZSESSIONEXPIRED in this case. |
There was a problem hiding this comment.
Looks ok, but because we can't distinguish requests that have failed for sure and those that have probably failed, this branch can execute in more cases than needed.
For the original library only the ZCONNECTIONLOSS and ZOPERATIONTIMEOUT error codes signified that the status of the operation is unknown. Other errors meant that the operation didn't take place. It makes sense to distinguish these cases in our library too: e.g. when we don't send the request because the session has already expired, then we are sure that the operation didn't take place and can safely throw out the new part.
There was a problem hiding this comment.
Ok. I also had the same thoughts,
but it is resolved by the fact that we check for session expiration (and also allocating block number) not long before and the number of false positive cases (when the operation is actually failed) will be insignificant comparing to previous implementation.
… not been processed #2939
No description provided.