Testcafe-hammerhead: ERROR browser disconnected. This problem may appear when a browser hangs or is closed, or due to network issues.

Created on 30 Apr 2019  路  7Comments  路  Source: DevExpress/testcafe-hammerhead

Hi all,

We decided to move away from web servers and host our front and backoffice applications though AWS cloudfront. So we have AWS cloudfront serving static assets from AWS S3 bucket and Dynamic application from AWS ALB which has our servers behind it. In short we removed Apache web server with S3 and ALB combination.

When we ran the login script against the one hosted on the S3 bucket, we started seeing the below behaviour with testcafe. Note, that this test works fine when pointed to the original implementation.

What is your Test Scenario?

  1. Navigate to the backoffice url
  2. Enter login credentials
  3. Validate that the homepage has opened up successfully

Link to the video

https://drive.google.com/open?id=1tkKuhhXLK6oVPrcZg1YvnzRyE08n3rpM

What is the Current behavior?

Post clicking on the Login button, the page is stuck in constant loading state. The network traffic for this has been attached above.

What is the Expected behavior?

The user must be navigated to the login page as expected.

What is聽your web application and聽your TestCafe聽test code?

SAP Hybris backoffice web application - built with ZK Framework

Command line error

ERROR The Chrome 73.0.3683 / Mac OS X 10.14.4 browser disconnected. This problem may appear when a browser hangs or is closed, or due to network issues.

Your Environment details:

  • testcafe version: 1.1.3
  • node.js version: 10.15.1

*command-line arguments:
testcafe chrome ./tests/backofficeloginuser.js --skip-js-errors --env=test --locale=backoffice

docker run --shm-size=1g -v $(pwd):/web-ui-test -t testcafe/testcafe "chromium" web-ui-test/tests/BackofficeLoginUser.js --skip-js-errors --env=test --locale=backoffice

Browser and OS version

HeadlessChrome 73.0.3683 / Mac OS X 10.14.4
Chrome 73.0.3683 / Mac OS X 10.14.4

client level 2 cookie bug

Most helpful comment

Hi @Avinger27
Thank you for the provided information. I've reproduced the problem.

For team: the problem is in our cookie processing mechanism. It looks like we don't remove our temporary cookies on the tested site.
image
This leads to 431 HTTP status code (Request Header Fields Too Large) for any requests.

All 7 comments

Could you please provide us with access to your website? We need it to research the issue in detail. If you cannot share it here you can send the account information at [email protected]

@AlexKamaev The access details are on their way to you now

Hi @Avinger27
Thank you for the provided information. I've reproduced the problem.

For team: the problem is in our cookie processing mechanism. It looks like we don't remove our temporary cookies on the tested site.
image
This leads to 431 HTTP status code (Request Header Fields Too Large) for any requests.

Going to pile on here and report that this is an issue my team is facing as well.

During a test run of 30 or so tests, we notice several 431 errors in the console messages. Most of the time it's to a resource that doesn't matter too much and the test continues unimpeded. Roughly every 10 to 15 tests, though, this happens on an important resource and the page is redirected to the chrome://error page for 431 errors. The test will hang there for a couple of minutes, and then the browser is restarted (by testcafe I'm assuming?) and the test carries on without reporting an error in the log files. This would only be slightly annoying, except that browserstack does not handle these reconnections gracefully and it often leads to the test stack hanging.

Hey, I'm seeing this issue within my project, is there any update around this bug? @miherlosev

Hello @bon960 ,

This bug is not fixed yet. We will update this thread as soon as we have any news regarding the issue.

2398 implemented lifted the max header size limit to the old default (80kB) and added a descriptive error message for the header overflow error. The error message suggests adding the --max-http-header-size=XXXX' to theNODE_OPTIONS` environment variable. When a header overflow error is thrown, we detect the problematic header, measure its size and calculate the recommended limit to be as twice as the problematic header size. The recommended limit is included in the error message, so you can just copy suggested instructions to your terminal or build scripts to avoid the error.

Was this page helpful?
0 / 5 - 0 ratings