Put the entry for the gpo reminder job back#9099
Conversation
e292390 to
d4035fc
Compare
|
This one looks pretty straightforward. Let's manually run that GPO confirmation code query to make sure we get the number of reminder emails we expect before we merge this. If you don't have the perms to run that lmk and I'm happy to help once #9080 lands |
|
@jmax-gsa and I just test drove the query from that branch. It appears to work as expected, however we observed it timing out occasionally with the default timeout. I am going to suggest making the query in a transaction with a longer timeout so that our job does not fail looking for profiles. Here is an example of what that pattern looks like form the report job: |
changelog: Upcoming Features, USPS verification, re-enable reminder job.
d4035fc to
ccd0a53
Compare
Moved `profiles_due_for_reminder` out to its own method and set up a constant for the database timeout.
jmhooper
left a comment
There was a problem hiding this comment.
Approved with one small nit about the timeout
| @@ -1,16 +1,11 @@ | |||
| class GpoReminderSender | |||
| LOCAL_DATABASE_TIMEOUT = 60_000 | |||
There was a problem hiding this comment.
this seems like the kind of thing better suited to be a config value than a constant, IMO, because the size of the tables, etc changes over time and having to do a code deploy to change that is not optimal
🎫 Ticket
LG-9565
🛠 Summary of changes
The initial work on LG-9565 had an incorrect DB query. Hooper pushed a patch to disable the job, and I corrected the query. This PR is to re-enable the job after the updated query is merged.