{"push_id":1239445699,"size":1,"distinct_size":1,"ref":"refs/heads/fix/batch-routing","head":"bc6af68def5e2e9af755d97f1811a3378e7cfb60","before":"972da9d6f943603089896af7d04d1fc9f677a4bb","commits":[{"sha":"bc6af68def5e2e9af755d97f1811a3378e7cfb60","author":{"name":"Yannick Welsch","email":"4642e729622b34408794d8a9ed687701b7880d3c@welsch.lu"},"message":"Fix issue when relocation source and target routings are failed in same batch update\n\nPR #19715 made AllocationService less lenient, requiring ShardRouting instances that are passed to its applyStartedShards and\napplyFailedShards methods to exist in the routing table. As primary shard failures also fail initializing replica shards,\nconcurrent replica shard failures that are treated in the same cluster state update might not reference existing replica entries\nin the routing table anymore. To solve this, PR #19715 ordered the failures by first handling replica before\nprimary failures. There are other failures that influence more than one routing entry, however. When we have a failed shard entry\nfor both a relocation source and target, then, depending on the order, either one or the other might point to an out-dated shard\nentry. As finding a good order is more difficult than applying the failures, this commit re-adds parts of the ShardRouting\nre-resolve logic so that the applyFailedShards method can properly treat shard failure batches.","distinct":true,"url":"https://api.github.com/repos/ywelsch/elasticsearch/commits/bc6af68def5e2e9af755d97f1811a3378e7cfb60"}]}
{"actor":{"display_login":"ywelsch"}}