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

deps: upgrade puppeteer to 21.7.0 #15724

Merged
merged 7 commits into from
Jan 5, 2024
Merged

deps: upgrade puppeteer to 21.7.0 #15724

merged 7 commits into from
Jan 5, 2024

Conversation

adamraine
Copy link
Member

@@ -540,7 +540,8 @@ function waitForUserToContinue(driver) {
}
/* c8 ignore stop */

driver.defaultSession.setNextProtocolTimeout(2 ** 31 - 1);
// Do "- 51" instead of "- 1" because we always add 50ms for the Puppeteer timeout
driver.defaultSession.setNextProtocolTimeout(2 ** 31 - 51);
Copy link
Collaborator

@connorjclark connorjclark Jan 5, 2024

Choose a reason for hiding this comment

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

this timeout is a month, why did you bother reducing it by 50 ms? :P

It was likely set to this number before just to be the max value accepted by the protocol.

this should probably just be the same "big" value as the other one.

Copy link
Member Author

Choose a reason for hiding this comment

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

Sorry jinx on the PR update.

This one actually makes sense to be the max int32 since the users manually decides when to continue. I can imagine plenty of scenarios where I want to inspect the page for longer than 5 min.

*
* This is ~50 days which is as good as infinity for all practical purposes.
*/
const MAX_TIMEOUT = (2 ** 32 - 1) - PPTR_BUFFER;

Copy link
Collaborator

@connorjclark connorjclark Jan 5, 2024

Choose a reason for hiding this comment

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

(my previous comment still applies here - why the buffer)

Copy link
Collaborator

Choose a reason for hiding this comment

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

Is it because of test fake timers shenanigans?

Copy link
Member Author

Choose a reason for hiding this comment

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

Puppeteer timeouts need to fit into an int32. We add PPTR_BUFFER to the timeout later on so this is actually the largest number the user can provide without breaking Puppeteer.

Now that I think about it, we should probably make the condition for using MAX_TIMEOUT to be timeout > MAX_TIMEOUT not Number.isFinite(timeout)

Copy link
Collaborator

@connorjclark connorjclark Jan 5, 2024

Choose a reason for hiding this comment

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

thanks for explaining. those constraints (esp the "we add this number later") should be clarified in a comment. Or, we can just cap to max int just before giving to puppeteer (in which case we could just use infinity here)

currently it's minusing a small magic constant from a number that is a really long time, so it comes off as unnecessary precision (50 days vs 50 days minus a 20th a second...)

@adamraine adamraine merged commit 5142439 into main Jan 5, 2024
29 checks passed
@adamraine adamraine deleted the pptr_21.7.0 branch January 5, 2024 17:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Prevent puppeteer protocol timeouts
3 participants