SpookyJumpyBeans commented on PR #5223: URL: https://github.com/apache/solr/pull/5223#issuecomment-6515632153
Converting this to a draft because the fix needs a design decision. Nothing reliably distinguishes a RESTORE that failed from one that is still activating its shards. In Overseer mode, `markAllShardsAsActive` is queued and returns before the state changes, so a just-restored healthy collection briefly looks exactly like a failed one. That rules out the straightforward options: 1. **Deleting the collection on failure.** The delete can itself be refused, for example when the collection is in an alias, which leaves the same state behind. 2. **Re-activating shards on retry.** The shards come back active, but the missing replicas and the alias are never created. 3. **Refusing a retry when every shard is still under construction.** This rejects collections that restored successfully moments earlier. I see two directions: an explicit "restore in progress" marker on the new collection, cleared only on full success, or making shard activation synchronous. Is either acceptable, or is there a preferred approach? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
