Skip to content
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.

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

Temporary fix for deadlock on pagehide event evaluation when page.close is called #979

Merged
merged 3 commits into from
Jul 26, 2023

Conversation

ankur22
Copy link
Collaborator

@ankur22 ankur22 commented Jul 25, 2023

Description of changes

When we run the k6 browser module against a remote chrome instance, we've found that 1 or more VUs deadlock when running the test in this issue. What we have come to realise during the investigation is that the evaluate on the pagehide event when page.close is called seems to wait indefinitely for a response from chrome, that never seems to arrive.

This is a temporary fix where we use the page's defaultTimeout to timeout this evaluate request instead of waiting indefinitely. We still need to investigate the root cause of the issue. The downside of this fix is that when this evaluate does timeout then we may not receive all the web vital measurements for that iteration (the reason we added the pagehide event evaluate was to force the web vital measurements to be calculated and sent to the browser module: #953).

Doesn't close issue #971 but temporarily alleviates the issue.

Checklist

This new EvaluateWithContext will allow us to pass in a context with a
timeout. For issue #971, we're seeing that often the evaluate to hide
the page on page.close ends up in a deadlock (waiting for the response
from the chrome browser after executing the CDP evaluate command). We
are not sure of the root cause of the issue, but this fix will help
prevent this deadlock allow the test run to complete in a timely
manner without it causing a time out error.
Now we can use the EvaluateWithContext from page.close when we call
evaluate to hide the page. We're going to rely on the default timeout
for now, and refine the timeout if we see this occurring too often --
if we see this occur too often this will affect the test result
depending on the default timeout (which is 30 seconds unless
overridden by the user).
Copy link
Collaborator

@ka3de ka3de left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

Copy link
Member

@inancgumus inancgumus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's interesting! Have you tried using ExecuteWithoutExpectationOnReply?

@ankur22
Copy link
Collaborator Author

ankur22 commented Jul 26, 2023

That's interesting! Have you tried using ExecuteWithoutExpectationOnReply?

That is a good solution, and a cleaner way in avoiding having to wait on the response. I did consider a similar approach, but my concern with that was that we would hide the problem, but this is only meant as a temporary fix with a constant reminder (whenever we see the warning) that there is an underlying issue that needs to be dealt with.

@ankur22 ankur22 merged commit 0fcdd36 into main Jul 26, 2023
12 checks passed
@ankur22 ankur22 deleted the fix/971-vu-deadlock branch July 26, 2023 09:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants