Today we log a "deleting snapshots [...] from repository [...]" message at INFO level [almost the first thing](https://github.com/elastic/elasticsearch/blob/dfaec0dbf0c8a0ba2912381334019725848f1f5a/server/src/main/java/org/elasticsearch/snapshots/SnapshotsService.java#L1886-L1888) when we start the deletion. However, the requested snapshots may not exist or they may be wildcards to be matched against actual snapshots. In these cases, the log message is either misleading or insuffiicent. Instead we should log the message after we have successfully added the delete to the cluster state similar to how the [logging works for snapshot creation](https://github.com/elastic/elasticsearch/blob/f77c16b78bab5e9f3ee24974aeba408e254e8c94/server/src/main/java/org/elasticsearch/snapshots/SnapshotsService.java#L3804).
server/src/main/java/org/elasticsearch/snapshots/SnapshotsService.java
return status != null && status.state() == ShardState.QUEUED;
    }
    /**
     * State machine for updating existing {@link SnapshotsInProgress.Entry} by applying a given list of {@link ShardSnapshotUpdate} to
     * them. The algorithm implemented below works as described
     * below:
     * Every shard snapshot or clone state update can result in multiple snapshots being updated. In order to determine whether or not a
     * shard update has an effect we use an outer loop over all current executing snapshot operations that iterates over them in the order
     * they were started in and an inner loop over the list of shard update tasks.
     *
     * If the inner loop finds that a shard update task applies to a given snapshot and either a shard-snapshot or shard-clone operation in
     * it then it will update the state of the snapshot entry accordingly. If that update was a noop, then the task is removed from the
     * iteration as it was already applied before and likely just arrived on the master node again due to retries upstream.
     * If the update was not a noop, then it means that the shard it applied to is now available for another snapshot or clone operation
     * to be re-assigned if there is another snapshot operation that is waiting for the shard to become available. We therefore record the
     * fact that a task was executed by adding it to a collection of executed tasks. If a subsequent execution of the outer loop finds that
     * a task in the executed tasks collection applied to a shard it was waiting for to become available, then the shard snapshot operation
     * will be started for that snapshot entry and the task removed from the collection of tasks that need to be applied to snapshot
     * entries since it can not have any further effects.
     *
     * Package private for testing.
     */
    static final class SnapshotShardsUpdateContext {
        
        private int changedCount = 0;
        
        private int startedCount = 0;
        
        private final ClusterStateTaskExecutor.BatchExecutionContext<SnapshotTask> batchExecutionContext;