feat: scope immediate notification email batching per user (backport #38866)#38886
Conversation
* feat: scope immediate notification email batching per user Immediate-email batching was scoped by user AND course_id, so a learner enrolled in multiple active courses received a separate buffered digest per course. Notification preferences are now account-level, so batching should feel account-level from the learner's perspective too. Scope the buffer by user only in decide_email_action, schedule_digest_buffer and send_buffered_digest: the first eligible notification is sent immediately, and additional immediate notifications within NOTIFICATION_IMMEDIATE_EMAIL_BUFFER_MINUTES are grouped into a single digest regardless of which course generated them. The digest already resolves per-notification course names, so multi-course digests render unchanged. course_key is retained in send_buffered_digest's signature so digest tasks enqueued before the change still deserialize. Closes openedx/tutor-contrib-platform-notifications#66 * fix: anchor buffered digest to last immediate email so wait stays buffer_minutes The digest was scheduled buffer_minutes from when the SECOND notification was processed, so the total wait after the immediate email was (gap to 2nd notification) + buffer_minutes -- observed as ~22 min for a 15 min buffer. Anchor scheduled_time to last_sent.email_sent_on + buffer_minutes instead, and clamp to now() when that window has already elapsed. Add tests for both the relative-to-last-email schedule and the already-elapsed fast path.
|
Thanks for the pull request, @AhtishamShahid! This repository is currently maintained by Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review. 🔘 Get product approvalIf you haven't already, check this list to see if your contribution needs to go through the product review process.
🔘 Provide contextTo help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:
🔘 Get a green buildIf one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green. DetailsWhere can I find more information?If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources: When can I expect my changes to be merged?Our goal is to get community contributions seen and reviewed as efficiently as possible. However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:
💡 As a result it may take up to several weeks or months to complete a review and merge your PR. |
Backport of #38866 to
release/verawood.Cherry-pick of merged commit
0cbeaec1712e48562bdc9ce1452fd15a9172f430(squash of #38866). Applied cleanly with no conflicts.Original PR summary
Scopes the immediate-notification email batching per user instead of per user+course:
decide_email_actionno longer filters recent notifications bycourse_id, so a recent immediate email for any enrolled course now buffers subsequent immediate notifications into one digest.schedule_digest_bufferanchors the digest ETA to the user's last immediate email (last_sent.email_sent_on+buffer_minutes), falling back tonowif that window already elapsed.send_buffered_digestcollects all scheduled notifications for the user across every course;course_keyis retained in signatures for compatibility but no longer filters.Original PR: #38866