git lfs prune --verify-remote behave unexpectedly

[alanedwardes]

git lfs prune --verify-remote behave unexpectedly

[alanedwardes]

Hi,

Thanks for the report! Can you include some anomyised logs of the request/responses with the environment variable GIT_TRACE=1? I'm looking to track down the specific requests that respond positively when they shouldn't.

Thanks,
Alan

[elfmimi]

Here you are. I've also added GIT_CURL_VERBOSE=1 to see headers and contents of the POST request.

log-with-empty-bucket.txt
The lambda is connected to a newly created empty bucket. So there exist no object to download at all.

log-with-server-down.txt
Throttling the lambda with setting concurrency down to zero, the api returns an error. but it is being treated correctly as negative, no file exists, answer.

[alanedwardes]

Thanks for the additional information - it looks like this particular git lfs operation doesn't follow the signed URL, so it doesn't actually verify whether it can get the data.

I'll count this as a feature request, since it will require the batch download endpoint to ping S3 for each object it's asked to return to confirm it exists - I'll try to get to it within the next few weeks.

Thanks,
Alan

[alanedwardes]

For reference - I have started a new branch for the changes around this feature: https://github.com/alanedwardes/Estranged.Lfs/tree/fetch-object-metadata

[alanedwardes]

This was addressed with version 3.0.0 - Estranged.Lfs now makes HEAD requests in parallel to S3 to verify all requested objects exist. https://github.com/alanedwardes/Estranged.Lfs/releases

[elfmimi]

I wasn't expecting this would be solved in such a short time.
Thank you very much. @alanedwardes
note: I purchased act.II as a sign of appreciation.