[sameena1415]

Summary

Fixes the HQ Smoke Tests failures on staging: test_case_20_scheduled_report (failing daily since at least Oct 26) and the Nov 4 run where every worker's login timed out.

Description

1. test_case_20_scheduled_report (HQSmokeTests/testPages/reports/report_page.py)

The test failed on every scheduled staging run with TimeoutException: Timed out receiving message from renderer: 300.000 right after clicking Submit. It passes on production, EU and India.

Timed on staging (2026-11-05, qa-automation):

Step	Time
POST the scheduled report form	164 s
Load reports/saved/ right after	120+ s (timed out)

The report is saved (the rerun's cleanup kept finding and deleting it), but saving plus the redirect takes longer than Chrome's 300 s page load limit.

Change: new submit_scheduled_report() allows up to 600 s for this step only, then restores the 300 s default. It still requires HQ's success message, and verify_scheduled_report() still checks the report row, so a report that isn't saved still fails. When the save takes over 60 s it prints a [WARN] with the elapsed time, so the staging slowness stays visible in the logs.

2. Login fixture (common_utilities/fixtures.py)

In the Nov 4 run (41786613163) all four workers timed out loading the staging login page at the start, erroring 16 tests. When LoginPage failed, the fixture never quit the browser, leaving hung Chrome processes on the runner, and each hang cost 300 s.

Change: cap the login page load at 120 s, quit the broken browser, and retry once with a new one after 15 s. The page load timeout goes back to 300 s after login. This fixture is shared, so other suites using it get the same behaviour.

Testing

• test_case_20_scheduled_report run locally (headless Chrome, Python 3.13) against staging: passed. Save + redirect took 350 s and logged the [WARN]; the report was found and then deleted.
• The login retry is not exercised by a real run; the staging login outage could not be reproduced.

Notes for review

• The margin is thin: 350 s measured vs. a 600 s limit. If staging gets slower, this test will fail again.
• The real issue is staging performance in HQ: saving a scheduled report in qa-automation takes over 5 minutes. Worth raising with the HQ team.

Link to Jira Ticket (if applicable)

None.

QA Checklist

• Label(s) and Assignee added
• PR sent for review
• Documentation (if applicable) added/updated

🤖 Generated with Claude Code