Update Swirl, take two #2432
Merged
Update Swirl, take two #2432
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is a second attempt at rust-lang#2269, which had to be reverted shortly after being deployed, as it caused jobs to fail to run in production. This commit only differs from that PR in the revision of swirl used. The cause of the issue was the change in the signature of `update_downloads`, which does not need anything from the job environment, and so it only takes a connection. This changed the environment type for that job from `background_jobs::Environment` to `()`, so our runner no longer knew how to run that job. The smallest fix in crates.io would have been to add an unused environment argument to `update_downloads`. However, having some jobs not require a shared environment felt common enough that I fixed this in swirl instead. sgrif/swirl#23 changed the behavior so jobs with no environment (a.k.a. the environment type is `()`) are always run, regardless of the environment type of the runner. Since `update_downloads` is essentially a cron job, and is not enqueued from the web server directly, this was not caught by our integration suite. This case was caught quickly after being deployed, and only affected a non-critical part of the service, so I've opted not to figure out how to add this to our integration suite.
JohnTitor
approved these changes
Apr 16, 2020
|
Looks good to me! I've tested locally and confirm that publish, yank/unyank, update_downloads, and dump_db all work for me. @bors r+ |
|
📌 Commit 97d7fc8 has been approved by |
|
☀️ Test successful - checks-travis |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This is a second attempt at #2269, which had to be reverted shortly
after being deployed, as it caused jobs to fail to run in production.
This commit only differs from that PR in the revision of swirl used.
The cause of the issue was the change in the signature of
update_downloads, which does not need anything from the jobenvironment, and so it only takes a connection. This changed the
environment type for that job from
background_jobs::Environmentto(), so our runner no longer knew how to run that job.The smallest fix in crates.io would have been to add an unused
environment argument to
update_downloads. However, having some jobsnot require a shared environment felt common enough that I fixed this in
swirl instead. sgrif/swirl#23 changed the
behavior so jobs with no environment (a.k.a. the environment type is
()) are always run, regardless of the environment type of the runner.Since
update_downloadsis essentially a cron job, and is not enqueuedfrom the web server directly, this was not caught by our integration
suite. This case was caught quickly after being deployed, and only
affected a non-critical part of the service, so I've opted not to figure
out how to add this to our integration suite.
r? @jtgeibel