sarkaramrit1993 commented on PR #5161: URL: https://github.com/apache/solr/pull/5161#issuecomment-6400786672
Thanks for the look. You're right that an aliased DELETE runs the cleanup on the alias name. I'd keep it out of this PR though. The legacy cleanup is best-effort: it already skips collections deleted before the upgrade, and it only matters once per cluster. Aliased DELETE also needs `followAliases=true`, which is opt-in. The finding does point at something bigger that's already on main. Collection API locks are keyed on the raw request name in both modes ([`DistributedCollectionConfigSetCommandRunner`](https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/cloud/api/collections/DistributedCollectionConfigSetCommandRunner.java), [`OverseerCollectionMessageHandler`](https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/cloud/api/collections/OverseerCollectionMessageHandler.java)), so an aliased op and a direct op on the same collection don't block each other. Filed [SOLR-18589](https://issues.apache.org/jira/browse/SOLR-18589) for that. -- 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]
