mreutegg commented on code in PR #2467:
URL: https://github.com/apache/jackrabbit-oak/pull/2467#discussion_r2294018574
##########
oak-segment-azure/src/main/java/org/apache/jackrabbit/oak/segment/azure/AzureArchiveManager.java:
##########
@@ -80,38 +80,16 @@ public AzureArchiveManager(BlobContainerClient
readBlobContainerClient, BlobCont
@Override
public List<String> listArchives() throws IOException {
try {
- List<String> archiveNames =
readBlobContainerClient.listBlobsByHierarchy(rootPrefix).stream()
+ return
readBlobContainerClient.listBlobsByHierarchy(rootPrefix).stream()
Review Comment:
I agree on the need to improve the archive delete operation and we can
certainly do it in a separate task.
> The code in `trunk` right now assumes the archive is empty if the segment
"0000.*" is absent. If we do filtering based on that, the question is how to
distinguish intentional archive deletion from data corruption, when a segment
is deleted or not successfully uploaded for any reason.
The first segment with position 0000 should only be deleted when the archive
is deleted. I'm not aware of another code path where this happens. Or you mean
when someone manually deletes the blob in Azure? If the segment is not
successfully uploaded, then the segment write should simply fail or retried.
Can you clarify why this is relevant in this context?
My concern is that not filtering out those archives anymore in
AzureArchiveManager.listArchives() is a change in behavior. There must be a
reason why the code in trunk filters out those archives. Is this not relevant
anymore? Why?
--
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: oak-dev-unsubscr...@jackrabbit.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
