Closed Wilhop closed 2 years ago
page.goto: net::ERR_CONNECTION_RESET
indicates network issues, is your web app available on internet so that you can actually connect to it from Azure or do you have to be in the same internal network? What URLs are failing?
The address is a baseUrl staging environment in the format of: https://myapplicaton.online.fi/environment/ - obviously had to mask the real address. -The address is publicly available -I would say Azure virtual agent can connect to it, because < 50% of the tests do pass and perform the login action correctly -I have never seen this behavior when running the tests locally -So to recap: the failing URL is the main login page of the application https://myapplicaton.online.fi/environment/
Also: I'll try to create a reproducible test repo, but haven't managed yet.
From pw:api log => page.goto started +1ms pw:api navigating to "https://myapplicaton.online.fi/environment/", waiting until "load" +0ms pw:api <= page.goto failed +420ms
Standard log showing failure:
page.goto: net::ERR_CONNECTION_RESET at https://myapplicaton.online.fi/environment/
=========================== logs ===========================
navigating to "https://myapplicaton.online.fi/environment/", waiting until "load"
============================================================
6 | console.log(`beforeEach initiated, running ${testInfo.title}`);
7 | const lg = new login(page);
> 8 | await lg.loginToAppWithAllLicenses();
| ^
From the html report, you failure shows a blank page
Any tips on what to try or workarounds are welcome :) This is a showstopper problem for us as the tests need to run in Azure Pipelines in order to bring us some value. I tried to simplify the problem so that there is no beforeEach and that the test uses storage so that it doesn't have to try and login each time. The same problem persists with page.goto: net::ERR_CONNECTION_RESET
Here is an example pw:api log with a simple test with 1 worker:
test.describe('Azure Pipelines test suite', () => {
test.use({ storageState: 'state.json' });
test("that all cards are present", async ({ page, context }) => {
await page.goto('https://myapp.application.fi/company/12345/100/as12d3/app/home');
Running 3 tests using 1 worker
pw:api => browserType.launch started +0ms
pw:api <= browserType.launch succeeded +418ms
pw:api => browser.newContext started +4ms
pw:api navigating to "https://myapp.application.fi/", waiting until "load" +165ms
pw:api "commit" event fired +21ms
pw:api navigated to "https://myapp.application.fi/" +0ms
pw:api "load" event fired +2ms
pw:api "domcontentloaded" event fired +1ms
pw:api <= browser.newContext succeeded +25ms
pw:api => browserContext.newPage started +6ms
pw:api <= browserContext.newPage succeeded +108ms
pw:api => page.goto started +3ms
pw:api navigating to "https://myapp.application.fi/company/12345/100/as12d3/app/home", waiting until "load" +1ms
pw:api <= page.goto failed +3s
pw:api => page.screenshot started +3ms
pw:api taking page screenshot +1ms
pw:api "commit" event fired +74ms
pw:api navigated to "chrome-error://chromewebdata/" +0ms
pw:api "load" event fired +2ms
pw:api "domcontentloaded" event fired +0ms
pw:api <= page.screenshot succeeded +98ms
One additional finding: The same test "plainLogin.spec.ts" works when it is run the first time -> 1st time test succeeds When the same test is run again the second time, it will fail with -> 2nd time test fails with ERR_CONNECTION_RESET
Here is the part of azure-pipelines.yml where the first test run succeeds and the second one will fail
# Succeeds
- task: CmdLine@2
displayName: 'Run the tests 1 and set environment variable CI=true'
inputs:
script: 'set CI=true && set DEBUG=pw:api && npx playwright test ./login/plainLogin.spec.ts'
- publish: $(System.DefaultWorkingDirectory)/state.json
displayName: 'Publish cached login data as state.json artifact'
artifact: state-json
condition: succeededOrFailed()
# Fails
- task: CmdLine@2
displayName: 'Run the tests again and set environment variable CI=true'
inputs:
script: 'set CI=true && set DEBUG=pw:api && npx playwright test ./login/plainLogin.spec.ts'
I tested the same workflows in the same URL with Cypress, and I didn't face any network issues there. Is there something in the way Playwright communicates that we could investigate?
We managed to get rid of the error messages by moving the test environment to Azure. I'm unsure of the real reason for the errors, because the same address worked with other test automation frameworks. Eg. same tests with Cypress worked just fine.
I'm guessing the errors come from a combination of Playwright + Server side firewall configuration. We're still checking if we can find out from the server's side what is the root cause of this.
I have had the exact same issues in Azure Pipelines with both Playwright and Cypress for a long time when running tests against our test environment (production working fine). Both hosted on Azure Container Apps. We eventually saw the same issues locally when accessing the site through VPN. In front of the servers we use Azure Front Door with caching enabled and a WAF. We concluded that the WAF was not the problem and eventually got our tests working by bypassing the cache. We do not yet understand why the cache is a problem though, it does work with the cache in the production environment.
Discussed in https://github.com/microsoft/playwright/discussions/16744
Here is an example screenshot that shows a totally blank page on a failing test