Skip to content

DS-943 Fixing integration tests for sonar issues fixes #1146

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.

Sign up for GitHub

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

Merged
ajmu1 merged 1 commit into from
Jan 2, 2026
Merged

DS-943 Fixing integration tests for sonar issues fixes #1146

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion application/event_replay/event_replay.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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)
Expand Down
2 changes: 1 addition & 1 deletion application/ingest_change_event/ingest_change_event.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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()
Expand Down
2 changes: 1 addition & 1 deletion application/service_matcher/service_matcher.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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()
Expand Down
2 changes: 1 addition & 1 deletion application/service_sync/service_sync.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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)


Expand Down
24 changes: 12 additions & 12 deletions test/integration/features/F006_Opening_Times.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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
Expand Down
Loading