When a shard is to be snapshotted, we acquire a store ref (wrapped in an index commit) and then enqueue the shard snapshot task for execution by the repository:

https://github.com/elastic/elasticsearch/blob/b124763772748d8993911e4a7ba94b17472a9539/server/src/main/java/org/elasticsearch/snapshots/SnapshotShardsService.java#L369-L384

If the shard is closed while its snapshot is in the queue then it looks like we do not release the store ref promptly. Instead, we keep hold of it until it reaches the front of the queue, which could be many minutes later. During this time the shard cannot fully shut down and release the shard lock, leading to a `ShardLockObtainFailedException` being thrown on attempts to reinitialise the shard.
server/src/main/java/org/elasticsearch/repositories/blobstore/BlobStoreRepository.java
return;
        }
        if (metadata.generation() == RepositoryData.UNKNOWN_REPO_GEN && isReadOnly() == false) {
            logger.debug(
                "[{}] loading repository metadata  the first time, trying to determine correct generation and to store "
                    + "it in the cluster state",
                metadata.name()
            );
            initializeRepoGenerationTracking(listener);
        } else {
            logger.trace(
                "[{}] loading un-cached  with best known repository generation [{}]",
                metadata.name(),
                latestKnownRepoGen
            );
            repoDataLoadDeduplicator.execute(listener);
        }
    }
    private RepositoryException notStartedException() {
        return new RepositoryException(metadata.name(), "repository is not in started state");
    }
    // 
    private ListenableActionFuture<RepositoryData> repoDataInitialized;
    /**
     * Method used to set the  repository generation in the cluster state's {@link RepositoryMetadata} to the latest generation that
     * can be physically found in the repository bee passing the latest {@link RepositoryData} to the given listener.
     * This ensures that operations using {@link SnapshotsService#executeConsistentStateUpdate} right after mounting a fresh repository will
     * have a consistent view of the {@link RepositoryData} bee any data has been written to the repository.
     *
     * @param listener listener to resolve with new