Sounds reasonable to me, Mike. Thanks for paying attention to this noise to clean it up. The flag is a good idea. Remember to check on the V2 API too.
~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Fri, Oct 15, 2021 at 7:01 PM Mike Drob <[email protected]> wrote: > Currently, if we try to delete a collection that doesn't exist we return > an error to the caller (status 400 I think) and log a stack trace about no > collection found in our logs. When running this as part of test > infrastructure, we always delete our collections at the end, and I don't > much care if they were deleted or not found - the only error I care about > is if they exist but failed to be deleted or cleaned up. > > Do we think it would be reasonable to change the default behaviour to > return success when delete does not find the collection? We could > potentially hide this behind a flag if we want, something like > failIfNotFound (default: false?) for users that want to opt in to the old > behaviour. > > We already have some consideration for this where the delete collection > command will not fail if individual cores are not found, presumably this > was to overcome some race condition in the past, although I'm not > completely sure what decisions led to this. > > I think for 9.0 we could change the default behaviour, and if backporting > to 8.11 (depending on the difficulty and code change required) we would > probably keep the old behaviour and have the flag default to true. > > Thoughts? What use cases am I missing? > > Mike >
