Split up consent request and reminder jobs #3328
Merged
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
thomasleese
force-pushed
the
refactor-enqueue-jobs
branch
from
aca1638 to
b7813df
Compare
thomasleese
force-pushed
the
refactor-enqueue-jobs
branch
from
b7813df to
df77617
Compare
thomasleese
force-pushed
the
refactor-enqueue-jobs
branch
from
df77617 to
15272af
Compare
thomasleese
force-pushed
the
refactor-enqueue-jobs
branch
2 times, most recently
from
7edeb3b to
c466686
Compare
To `SendVaccinationConfirmationsJob` to match the naming convention with the other jobs that send out communications.
To `EnqueueUpdatePatientsFromPDSJob` as this is the naming convention we'll use for jobs which do nothing but queue up other jobs.
To `EnqueueClinicSessionInvitationsJob` as this better reflects that the job is only responsible for enqueing other jobs.
To `SendSchoolSessionRemindersJob` to reflect that this job actually sends the communications rather than just enqueing other jobs.
This splits the job in to two separate jobs, one which runs on a schedule and for each session queues up a separate job which handles the process of sending the communications for a particular session. We're finding that the current job is unable to handle a high number of sessions and runs out of resources. Instead, by queuing a job for each session we can avoid the individual jobs being too resource hungry and gives us more flexibility in terms of running the jobs manually.
This splits the job in to two separate jobs, one which runs on a schedule and for each session queues up a separate job which handles the process of sending the communications for a particular session. We're finding that the current job is unable to handle a high number of sessions and runs out of resources. Instead, by queuing a job for each session we can avoid the individual jobs being too resource hungry and gives us more flexibility in terms of running the jobs manually.
thomasleese
force-pushed
the
refactor-enqueue-jobs
branch
from
c466686 to
330bd08
Compare
|
misaka
approved these changes
Apr 15, 2025
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 splits the jobs in to two separate jobs each, one which runs on a schedule and for each session queues up a separate job which handles the process of sending the communications for a particular session.
We're finding that the current job is unable to handle a high number of sessions and runs out of resources. Instead, by queuing a job for each session we can avoid the individual jobs being too resource hungry and gives us more flexibility in terms of running the jobs manually.
As part of this change I've also renamed the other jobs for consistency, specifically jobs which are prefixed with
Enqueuedo nothing other than queue up other jobs, and jobs prefixed withSenddo the task of actually sending out communications.