Description
Running the following query returns 356 rows from 2019-11-07. These crates have an aggregate net over-count of 1,727 downloads.
SELECT * FROM version_downloads WHERE processed = 't' AND downloads != counted;This was likely due to multiple update_downloads background jobs running concurrently during a UTC date rollover. Since #2539, that should no longer happen.
I propose that we run the following query against the database, and then allow the normal background job to fixup the download counts. The background job adjusts counts by an amt: i32 and will apply negative download counts if necessary.
BEGIN;
UPDATE version_downloads SET processed = 'f' WHERE downloads != counted AND processed = 't';
COMMIT;The processed = 't' in the WHERE clause is not strictly necessary, but avoids unnecessary updates to today's rows and allows for confirmation that only the expected 356 rows were updated before committing the transaction.
After the background job is next run, the following query can be run to ensure that there are no remaining inconsistencies.
SELECT * FROM version_downloads WHERE downloads != counted AND date < now()::date;