{"push_id":1476830716,"size":1,"distinct_size":1,"ref":"refs/heads/5.x","head":"32b421aba24ab35949746cbccc98335f6f0bf161","before":"524d9bb6d1aee39824a1b84f5b7cc6ff5d624e01","commits":[{"sha":"32b421aba24ab35949746cbccc98335f6f0bf161","author":{"name":"Yannick Welsch","email":"4642e729622b34408794d8a9ed687701b7880d3c@welsch.lu"},"message":"Use a fresh recovery id when retrying recoveries (#22325)\n\nRecoveries are tracked on the target node using RecoveryTarget objects that are kept in a RecoveriesCollection. Each recovery has a unique id that is communicated from the recovery target to the source so that it can call back to the target and execute actions using the right recovery context. In case of a network disconnect, recoveries are retried. At the moment, the same recovery id is reused for the restarted recovery. This can lead to confusion though if the disconnect is unilateral and the recovery source continues with the recovery process. If the target reuses the same recovery id while doing a second attempt, there might be two concurrent recoveries running on the source for the same target.\n\nThis commit changes the recovery retry process to use a fresh recovery id. It also waits for the first recovery attempt to be fully finished (all resources locally freed) to further prevent concurrent access to the shard. Finally, in case of primary relocation, it also fails a second recovery attempt if the first attempt moved past the finalization step, as the relocation source can then be moved to RELOCATED state and start indexing as primary into the target shard (see TransportReplicationAction). Resetting the target shard in this state could mean that indexing is halted until the recovery retry attempt is completed and could also destroy existing documents indexed and acknowledged before the reset.\n\nRelates to #22043","distinct":true,"url":"https://api.github.com/repos/NSIT/elasticsearch/commits/32b421aba24ab35949746cbccc98335f6f0bf161"}]}
{"actor":{"display_login":"pmvs-deploy"}}