DEV: Recover missing files of existing uploads (PR #10757)

UploadRecovery only worked on missing Upload records. Now it also works with existing ones that have an invalid_etag status.

The spec (it’s the first one that tests the S3 path) is a bit of stub-a-palooza, but that’s how much this class interacts with the the outside world. :man_shrugging:

GitHub

stub-a-palooza

I’m stealing this :wink:

We talked via other means, this may not interact well with secure uploads.

Maybe @martin-brennan you should have a look? :mag:

The spec (it’s the first one that tests the S3 path) is a bit of stub-a-palooza, but that’s how much this class interacts with the the outside world. man_shrugging

@CvX it is always a drag testing S3 stuff, I spent ages stubbing stuff out for a spec the other day.

We talked via other means, this may not interact well with secure uploads.

Why do we think this won’t interact well with secure uploads? The sha1 for secure uploads may not be a “real” sha1 but it is used in the S3 URL and everything. The only way to be super sure is a spec I suppose but it doesn’t look like this has changed much and if it was broken for secure uploads we would have noticed before now I guess?

Why do we think this won’t interact well with secure uploads?

When secure uploads are enabled this new codepath created duplicate uploads. I’ve added a spec and a fix in https://github.com/discourse/discourse/pull/10757/commits/a55b8c867b87034b9e0d0f4f76357c4a19c02aa9

1 Like