From 4acdd6aa25b40ed7902fdf082bdaa99f438071a5 Mon Sep 17 00:00:00 2001 From: Ajay Mudgal Date: Fri, 2 Jan 2026 15:35:50 +0000 Subject: [PATCH] Fixing integration tests for sonar issues fixes --- application/event_replay/event_replay.py | 2 +- .../ingest_change_event.py | 2 +- .../service_matcher/service_matcher.py | 2 +- application/service_sync/service_sync.py | 2 +- .../features/F006_Opening_Times.feature | 24 +++++++++---------- 5 files changed, 16 insertions(+), 16 deletions(-) diff --git a/application/event_replay/event_replay.py b/application/event_replay/event_replay.py index 341cc2eaf..842ac2510 100644 --- a/application/event_replay/event_replay.py +++ b/application/event_replay/event_replay.py @@ -15,7 +15,7 @@ # Configure boto3 client with explicit timeout to prevent hanging in Lambda # Timeouts tuned for typical DynamoDB/SQS operations while preventing indefinite hangs -boto_config = Config(connect_timeout=10, read_timeout=15) +boto_config = Config(connect_timeout=60, read_timeout=60) # Create clients at module level for connection reuse across Lambda invocations dynamodb_client = client("dynamodb", config=boto_config) diff --git a/application/ingest_change_event/ingest_change_event.py b/application/ingest_change_event/ingest_change_event.py index 26c0132ce..b880606f3 100644 --- a/application/ingest_change_event/ingest_change_event.py +++ b/application/ingest_change_event/ingest_change_event.py @@ -17,7 +17,7 @@ from common.utilities import extract_body, get_sequence_number # Configure boto3 client with explicit timeout to prevent hanging in Lambda -boto_config = Config(connect_timeout=10, read_timeout=15) +boto_config = Config(connect_timeout=60, read_timeout=60) logger = Logger() tracer = Tracer() diff --git a/application/service_matcher/service_matcher.py b/application/service_matcher/service_matcher.py index 97924872e..38eddcd38 100644 --- a/application/service_matcher/service_matcher.py +++ b/application/service_matcher/service_matcher.py @@ -18,7 +18,7 @@ from common.utilities import extract_body # Configure boto3 client with explicit timeout to prevent hanging in Lambda -boto_config = Config(connect_timeout=10, read_timeout=15) +boto_config = Config(connect_timeout=60, read_timeout=60) logger = Logger() tracer = Tracer() diff --git a/application/service_sync/service_sync.py b/application/service_sync/service_sync.py index 00ed6097d..b287c3c4e 100644 --- a/application/service_sync/service_sync.py +++ b/application/service_sync/service_sync.py @@ -21,7 +21,7 @@ tracer = Tracer() logger = Logger() -boto_config = Config(connect_timeout=10, read_timeout=15) +boto_config = Config(connect_timeout=60, read_timeout=60) sqs_client = client("sqs", config=boto_config) diff --git a/test/integration/features/F006_Opening_Times.feature b/test/integration/features/F006_Opening_Times.feature index a5676570e..cb26fa887 100644 --- a/test/integration/features/F006_Opening_Times.feature +++ b/test/integration/features/F006_Opening_Times.feature @@ -33,12 +33,12 @@ Feature: F006. Opening times @complete @opening_times Scenario: F006SXX6. Confirm recently added specified opening date can be removed from Dos Given a basic service is created - And the change event is "open" on date "Jan 01 2026" + And the change event is "open" on date "Jan 01 2027" When the Changed Event is sent for processing with "valid" api key - Then DoS is open on "Jan 01 2026" + Then DoS is open on "Jan 01 2027" Given the change event has no specified opening dates When the Changed Event is sent for processing with "valid" api key - Then there is no longer a specified opening on "Jan 01 2026" + Then there is no longer a specified opening on "Jan 01 2027" And the service history is updated with the "removed" specified opening times @complete @opening_times @@ -55,29 +55,29 @@ Feature: F006. Opening times @complete @opening_times Scenario: F006SX8. Additional date changes open to closed Given an entry is created in the services table - And the service is "open" on date "Jan 01 2026" + And the service is "open" on date "Jan 01 2027" And the entry is committed to the services table - And the change event is "closed" on date "Jan 01 2026" + And the change event is "closed" on date "Jan 01 2027" When the Changed Event is sent for processing with "valid" api key - Then DoS is closed on "Jan 01 2026" + Then DoS is closed on "Jan 01 2027" @complete @opening_times Scenario: F006SX9. Additional date changes closed to open Given an entry is created in the services table - And the service is "closed" on date "Jan 01 2026" + And the service is "closed" on date "Jan 01 2027" And the entry is committed to the services table - And the change event is "open" on date "Jan 01 2026" + And the change event is "open" on date "Jan 01 2027" When the Changed Event is sent for processing with "valid" api key - Then DoS is open on "Jan 01 2026" + Then DoS is open on "Jan 01 2027" @complete @opening_times Scenario: F006SX10. Additional date changes times changed Given an entry is created in the services table - And the service is "open" on date "Jan 01 2026" + And the service is "open" on date "Jan 01 2027" And the entry is committed to the services table - And the change event specified opening is "open" from "10:00" to "16:00" on date "Jan 01 2026" + And the change event specified opening is "open" from "10:00" to "16:00" on date "Jan 01 2027" When the Changed Event is sent for processing with "valid" api key - Then DoS is open from "10:00" until "16:00" on "Jan 01 2026" + Then DoS is open from "10:00" until "16:00" on "Jan 01 2027" And the "service-sync" lambda does not show "report_key" with value "BLANK_STANDARD_OPENINGS" @complete @opening_times