-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adjust start dates when fetching notification stats #2061
Changes from all commits
c5550f2
25c47fa
82abbbe
1d280a7
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -8,7 +8,7 @@ | |
from sqlalchemy.types import DateTime, Integer | ||
|
||
from app import db | ||
from app.dao.date_util import utc_midnight_n_days_ago | ||
from app.dao.date_util import get_midnight, utc_midnight_n_days_ago | ||
from app.models import ( | ||
EMAIL_TYPE, | ||
KEY_TYPE_NORMAL, | ||
|
@@ -239,7 +239,7 @@ def fetch_notification_status_for_service_for_day(bst_day, service_id): | |
|
||
|
||
def fetch_notification_status_for_service_for_today_and_7_previous_days(service_id, by_template=False, limit_days=7): | ||
start_date = utc_midnight_n_days_ago(limit_days - 1) | ||
start_date = utc_midnight_n_days_ago(limit_days) | ||
|
||
stats_for_7_days = db.session.query( | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. An idea that crossed my mind to make this code a bit more testable is pulling the Had this been the case from the beginning we would have caught on to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I like that idea, if you want to do it in this PR feel free |
||
FactNotificationStatus.notification_type.label("notification_type"), | ||
|
@@ -260,7 +260,7 @@ def fetch_notification_status_for_service_for_today_and_7_previous_days(service_ | |
*([func.count().label("count")]), | ||
) | ||
.filter( | ||
Notification.created_at >= start_date, | ||
Notification.created_at >= get_midnight(datetime.utcnow()), | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This line was the core of the issue that inflated the notification counts. We weren't pulling just today's notifications in this query, but all notifications from starting from This line was also why it seemed reasonable to start the investigation with jobs as it wasn't a 1:1 duplication but a duplication of In retrospect, investigating significantly higher volume services could have helped steer us away from that sooner as it's less likely a service would be sending large volumes of one offs. Certainly possible, but less likely to make sense to do so. |
||
Notification.service_id == service_id, | ||
Notification.key_type != KEY_TYPE_TEST, | ||
) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was hesitant to remove the
- 1
here as we added it in this PR for an edge case.Given this date is only compared to the
bst_date
inft_notification_counts
, which has no timezone data, we may not need the call toutc_midnight_n_days_ago
anymore.