LG-14030: Ensure roll plan 0032's rake task is available in all environments#10988
Conversation
| # bundle exec rake in_person_enrollments:backfill_sponsor_id | ||
| # | ||
| task backfill_sponsor_id: :environment do |_task, _args| | ||
| with_timeout do |
There was a problem hiding this comment.
are we able to use the Reports::BaseReport.transaction_with_timeout here?
| with_timeout do | |
| Reports::BaseReport.transaction_with_timeout do |
There was a problem hiding this comment.
Reports::BaseReport.transaction_with_timeout is new to me - I'm curious what it adds here?
There was a problem hiding this comment.
not having to re-implement a nearly-identical method below in this file?
There was a problem hiding this comment.
I looked at the config for dev, int, and staging and found that report_timeout was not set for any of those environments. When I checked in application.yml.default, the only environment that has a value set for report_timeout is production. This makes me think that in order to use the Reports::BaseReport.transaction_with_timeout method, whoever runs this task would first have to set the report_timeout config variable in dev, int, and staging. Is this correct?
There was a problem hiding this comment.
when the value is nil, it's an unlimited timeout
There was a problem hiding this comment.
TIL!
(Do we want an unlimited timeout?)
There was a problem hiding this comment.
sometimes we do! but we could also update the method to accept an explicit timeout if we wanted to hardcode that. I guess what I was aiming to get at was it might be nice to DRY some timeout code, but if this rake task is going away, maybe not worth the effort
There was a problem hiding this comment.
Yeah, I think the reason I’m balking at this proposed change is because it feels weird to have a piece of code that isn’t related to reports rely on the report_timeout variable.
jennyverdeyen
left a comment
There was a problem hiding this comment.
Ran the tests, looks good! LGTM!
shanechesnutt-ft
left a comment
There was a problem hiding this comment.
Looks good to me! 👍🏻
…onments (#10988) * restore rake task to backfill sponsor_id column in in_person_enrollments table * Changelog: Upcoming Features, In-person proofing, backfill sponsor id again * update in_person_enrollments factory and get tests passing * do clean up
Context: We need to run roll plan 0032 again before enhanced IPP launches, because we caught a bug where sponsor_id was not being set for all in_person_enrollments. PR #10984 fixed the bug. As noted in this jira comment on LG-13578, there are now in_person_enrollments with a nil sponsor_id in multiple environments. As a result, we need this rake task to be available in all environments.
🎫 Ticket
LG-14030: Ensure roll plan 0032's rake task is available in all environments
🛠 Summary of changes
📜 Testing Plan
Confirmed automated tests pass.