From 0d07220923f7bb7a76fab9b2f5531a239e45cc35 Mon Sep 17 00:00:00 2001 From: Ben Thorner Date: Tue, 5 Apr 2022 10:46:14 +0100 Subject: [PATCH 1/2] Fix log for sending SMS to be generic per client This was a mistake in [^1]. [^1]: https://github.com/alphagov/notifications-api/commit/3b082477f05588d638a21ce0874356678fd429df#diff-95316b574f974237b3b7ce453fec09628bd1062087154789ff4d0176ea23c460R52 --- app/clients/sms/__init__.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/app/clients/sms/__init__.py b/app/clients/sms/__init__.py index 38f3c55c9..a862680e0 100644 --- a/app/clients/sms/__init__.py +++ b/app/clients/sms/__init__.py @@ -59,7 +59,7 @@ class SmsClient(Client): finally: elapsed_time = monotonic() - start_time self.statsd_client.timing(f"clients.{self.name}.request-time", elapsed_time) - self.current_app.logger.info("Reach request for {} finished in {}".format(reference, elapsed_time)) + self.current_app.logger.info(f"{self.name} request for {reference} finished in {elapsed_time}") return response From 4a40b169a21c8c751c10a269f5c3c9bc962b5878 Mon Sep 17 00:00:00 2001 From: Ben Thorner Date: Tue, 5 Apr 2022 11:07:05 +0100 Subject: [PATCH 2/2] Fix flakey test for notification status This was creating data in the Notifications table but the funcetion under test was - now the timestamps are in the past - looking in the NotificationHistory table. Freezing the time of the test fixes that. --- tests/app/dao/test_fact_notification_status_dao.py | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/app/dao/test_fact_notification_status_dao.py b/tests/app/dao/test_fact_notification_status_dao.py index 8dbdb3b3d..9d00e874f 100644 --- a/tests/app/dao/test_fact_notification_status_dao.py +++ b/tests/app/dao/test_fact_notification_status_dao.py @@ -611,6 +611,7 @@ def test_get_total_notifications_for_date_range(sample_service): assert results[0] == ("2021-03-01", 15, 20, 3) +@freeze_time('2022-03-31T18:00:00') @pytest.mark.parametrize('created_at_utc,process_day,expected_count', [ # Clocks change on the 27th of March 2022, so the query needs to look at the # time range 00:00 - 23:00 (UTC) thereafter.