Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
Download.counts_by_day_for_version_in_date_range
method looks in redis to see if the download history is there (https://github.com/rubygems/rubygems.org/blob/master/app/models/download.rb#L79-L107 is the method in question at time of this writing).The test is putting data in redis and confirming the count returned by that method is correct. The test and method do work, so all is well. However, failing redis data, it falls back to searching VersionHistory records. Unfortunately, it looks like there are missing VersionHistory records in rubygems.org's production data.
Example:
rails-2.3.5
.Looking at https://rubygems.org/gems/rails/versions/2.3.5 it says the total download count for that version is aprox ~1M downloads. However, the api is returning a download count of 33k. Pretty weak comparison. The redis data is probably missing old data, and there no VersionHistory records in the database dump either. The dump is attached to this post on this branch.
Console with the dump:
But none for rails:
I don't have the redis dump, but given the data coming back from that method, it seems redis has missing data as well.
It looks like redis does have some download info on this gem, but only from march this year. The data coming back from the api (should be a sum of 1M but is only ~33k) returns 0's all the way from 26th of November until the 8th of March 4 years later.
Some more inconsistencies: https://gist.github.com/shaiguitar/d2af997b7f58e24fd305