Skip to content

Conversation

apata
Copy link
Contributor

@apata apata commented Oct 13, 2025

Changes

Starts retrying browserless.io 408 responses again. Experiments show that a request made in quick succession after a 408 timeout can succeed quickly. If it does not, there's now a hard cap on the check itself.

Tests

  • This PR does not require tests

Changelog

  • This PR does not make a user-facing change

Documentation

  • This change does not need a documentation update

Dark mode

  • This PR does not change the UI

@apata apata requested a review from a team October 13, 2025 15:50
# rate limit
429 -> {:delay, 1000}
# timeout
408 -> {:delay, 500}
Copy link
Contributor

Choose a reason for hiding this comment

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

In detection, given that the endpoint timeout is 5s, and we also delay the retry request by 500ms, I don't think it's realistic that the retry will finish in 500ms. I don't think I ever saw a successful request that fast -- even with a minimal Puppeteer function.

In verification, it could help though.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You're right, I had deluded myself into thinking maybe. I'll adjust it so 408 is retried in verification.

@apata apata requested a review from RobertJoonas October 14, 2025 07:04
@apata apata added the preview label Oct 14, 2025
Copy link

Preview environment👷🏼‍♀️🏗️
PR-5800

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants