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
