Change the get notifications for a month to call a new summary table

[jzbahrai]

Summary | Résumé

Change the get notifications for a month to call a new summary table
This is because the summary table only stores data for a month, vs day (which is what ft_notification_status does).
This table is a lot faster to answer the question how many notifications have been send by notify.

DONOT MERGE, will test this after code freeze and then merge

We can assume atleast the data in the table is correct, as if I go and query production, I see

select month, notification_type, sum(notification_count) from monthly_notification_stats_summary where month >='2025-11-01' and month <='2025-11-30' and service_id not in ('30b2fb9c-f8ad-49ad-818a-ed123fc00758', 'd6aa2c68-a2d9-4437-ab19-3ae8eb202553') group by 1, 2 ;
         month          | notification_type |   sum
------------------------+-------------------+---------
 2025-11-01 00:00:00+00 | sms               |  295562
 2025-11-01 00:00:00+00 | email             | 9261689

which is the same as

which currently calling ft_notification_status

(after this PR is merged, we will be using the new table)

[smcmurtry]

Code looks good, let's see what the results in staging look like

[Copilot]

Pull request overview

This PR optimizes the retrieval of monthly notification statistics by switching from the large ft_notification_status table (28M+ rows) to a new pre-aggregated monthly_notification_stats_summary table. The new table stores monthly aggregates rather than daily data, significantly improving query performance.

Key Changes:

• Modified fetch_delivered_notification_stats_by_month() to query the new MonthlyNotificationStatsSummary table instead of FactNotificationStatus
• Updated test fixtures to use create_monthly_notification_stats_summary() helper instead of create_ft_notification_status()
• Added new test helper function create_monthly_notification_stats_summary() with flexible month parameter handling

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
app/dao/fact_notification_status_dao.py	Refactored query to use MonthlyNotificationStatsSummary table with ordering by month (desc) and notification type
tests/app/db.py	Added create_monthly_notification_stats_summary() helper function with date/string conversion logic
tests/app/dao/test_fact_notification_status_dao.py	Converted tests to use monthly summary data; organized into TestFetchDeliveredNotificationStatsbyMonth class
tests/app/service/test_rest.py	Simplified test fixtures to use monthly summary helper instead of creating templates and ft_notification_status records

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Class name has inconsistent capitalization: 'Statsby' should be 'StatsBy' to follow Python naming conventions.

Suggested change

	class TestFetchDeliveredNotificationStatsbyMonth:
	class TestFetchDeliveredNotificationStatsByMonth:

[Copilot]

The strftime format forces day to '01' regardless of the input date's day. If a date like date(2019, 12, 15) is passed, it will be converted to '2019-12-01 00:00:00+00'. While this may be intentional for normalizing to the first of the month, the function should either document this behavior clearly in the docstring or validate that the input date's day is 1.

[Copilot]

The commented-out old implementation is extensive (lines 183-207) and makes the function harder to read. Since this is documented as the old approach, consider removing it or moving it to a separate documentation file, leaving only a reference to where the old implementation can be found if needed.