-
Notifications
You must be signed in to change notification settings - Fork 655
Adds tests for DownloadsCounter #3423
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This change will allow tests to inspect what the persist methods did, and still allows the application to log what happened.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. One minor comment, feel free to r=me (with or without addressing the comment).
Regarding the duplication of test code, I've never really understood why we put most tests in a separate test crate. I don't think it is necessary, and some of the test infrastructure we've built out in tests/all.rs
would be useful for tests in our lib crate. (Plus it is an extra crate that takes time to link. The only advantage that I see is that you can modify these tests without rebuilding the library and bin crates.)
In any case, I'm not worried about this duplication for now. We can look into improving our test infrastructure separately.
.pending_count | ||
.fetch_sub(counted_downloads as i64, Ordering::SeqCst); | ||
let old_pending = self.pending_count.fetch_sub( | ||
(counted_downloads + discarded_downloads) as i64, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we print a log message when discarded_downloads
is non-zero? I don't think we need to output it for every shard as part of PersistStats
, but in the rare case we delete a crate and hit this, it might be nice have a record in the logs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Honestly I'm not sure what the value of noticing this in the logs is. Could you provide an example?
@bors r=jtgeibel If we decide to log discarded crates I'll do that in a separate PR. |
📌 Commit c22ba7c has been approved by |
☀️ Test successful - checks-actions |
This fixes #3416 by adding tests for
DownloadsCounter
. There are a few notable things in this PR I'd like to highlight.First off, the tests are not implemented in
src/tests
, but are implemented in a#[cfg(test)] mod tests {}
in the same source file. While this resulted in some code duplication I had to do this because testingpersist_next_shard
requires access to the internals ofDownloadsCounter
and I'd prefer not to expose them.This PR also fixes a bug I discovered while writing the test for incrementing a missing version. Inserting a missing version ID in the
version_downloads
table doesn't work thanks to the foreign key, and aborts the wholeINSERT
statement (losing all the downloads in that shard). This could happen in production if a version is deleted between callingincrement()
and persisting that shard.To fix that bug I changed the code to do a
SELECT FOR SHARE
from theversions
table of the version IDs we're about to persist, discarding the versions that are not returned by the query. TheFOR SHARE
clause does the equivalent ofRwLock::read
, preventing other transactions from updating or deleting the selected rows while allowing otherSELECT
s andSELECT FOR SHARE
s.There were also some refactorings to make the tests better to write.
This PR is best reviewed commit-by-commit.
r? @jtgeibel