Async Propagation shows 4bytes on empty space

[kobergj]

          I discovered a bug: After running https://github.com/owncloud/cs3api-validator/pull/18 on my local ocis with async propagation, my space is empty but shows 4 bytes used.

I suspect we have an issue with deletion.

@butonic @aduffeck what happens if you delete a file A/B/C/testfile.txt and delete B before the propagation has been successful?

Originally posted by @micbar in #10655 (comment)

[dragonchaser]

Can not reproduce, need more info.

[aduffeck]

I also failed to reproduce it with manual testing, but the cs3-validator testsuite sometimes (only every 10th run or so) triggers it. I'm still trying to trace it down, but I noticed this error in the logs around the time the problem was triggered, which sounds related:

2024-12-10T09:47:48+01:00 ERR Propagation failed. Could not read node. error="internal error: Missing parent ID on node" method=async.Propagate nodeid=72cd9b5d-ffd3-4171-bf4b-b85bc11a86b9 parentid=29d97ebf-19ca-42cc-ab59-356c65c6aa00 pid=584371 pkg=rhttp request-id=gemini/YkkqQB1Gu1-000063 service=storage-users sizeDiff=4 spaceid=some-admin-user-id-0000-000000000000

[jvillafanez]

@butonic @aduffeck what happens if you delete a file A/B/C/testfile.txt and delete B before the propagation has been successful?

It seems it breaks the propagation. The "-4B" (or the corresponding size of the "testfile.txt") aren't removed because the propagation stops at either "A/B" or "A/B/C" because the node doesn't exist.
Folder "A" shouldn't have the 4B of the "testfile.txt", but it still has those 4B because of the broken propagation.

Problematic code seems to be https://github.com/cs3org/reva/blob/edge/pkg/storage/utils/decomposedfs/tree/propagator/async.go#L313-L317

Steps should be something like:

1. Create "A/B/C/testfile.txt" (the deeper the file is, the better)
2. Let the "A" folder update the size properly.
3. Remove the "testfile.txt"
4. Remove the "A/B" folder

Maybe, in order to reproduce the issue, we need to delay the async propagation long enough to let the steps 3 and 4 to finish. When the propagation from step 3 starts, it will break due to the missing parent folder and won't reach folder "A".

Maybe it's also easier to reproduce in big and deep folders because it could be easier to remove a parent folder while the propagation is still running due to server load or queued propagations

[kobergj]

@jvillafanez could you try reproducing it?

[jvillafanez]

#10729 (comment) might not be the problem, or at least not as easy as it's described.
The propagation for the "testfile.txt" is stopped. However, the deletion of the "A/B" folder triggers a new propagation, which removes the corresponding folder size from the parents. Basically, the "problem" caused with the halt of the propagation is fixed with the new propagation. In the end, giving enough time for the propagation to stabilize, the result will be the correct one.

If we consider that updating the size is atomic (or behaves in a similar way), it shouldn't be possible to propagate a wrong size unless the actual size was wrong in the first place.
Checking for possible issues when writing the changes might cause problems with the propagation due to missing data.

[jvillafanez]

Unless there is some kind of problem with the reading or writing of the data, I'm out of ideas of how to reproduce the issue using common operations.

It's true that the propagation might be delayed and the folder might show obsolete information (such as 4 bytes in a folder after deleting all the contents), but it should be updated with the right information after a while, when the propagation finishes.

Without clear steps to reproduce the issue, I'm assuming this is just a delay with the async propagation, so I'm closing the issue.