Feat add exp 429 retry - #46
Merged
Merged
Conversation
@testplane/devtools
eslint-plugin-wdio
@wdio/allure-reporter
@wdio/appium-service
@wdio/browser-runner
@wdio/browserstack-service
@wdio/cli
@wdio/concise-reporter
@testplane/wdio-config
@wdio/cucumber-framework
@wdio/dot-reporter
@wdio/firefox-profile-service
@wdio/globals
@wdio/jasmine-framework
@wdio/json-reporter
@wdio/junit-reporter
@wdio/lighthouse-service
@wdio/local-runner
@testplane/wdio-logger
@wdio/mocha-framework
@testplane/wdio-protocols
@testplane/wdio-repl
@wdio/reporter
@wdio/runner
@wdio/sauce-service
@wdio/shared-store-service
@wdio/smoke-test-cjs-service
@wdio/smoke-test-reporter
@wdio/smoke-test-service
@wdio/spec-reporter
@wdio/static-server-service
@wdio/sumologic-reporter
@wdio/testingbot-service
@testplane/wdio-types
@testplane/wdio-utils
@wdio/webdriver-mock-service
@testplane/webdriver
@testplane/webdriverio
commit: |
sonic16x
force-pushed
the
add-exp-429-retry
branch
from
August 11, 2026 10:57
b7cad1d to
1389b4f
Compare
DudaGod
requested changes
Aug 11, 2026
| * Base delay in ms for exponential backoff on 429 responses during session creation. | ||
| * If set, retries use exponential backoff instead of immediate retry. | ||
| */ | ||
| exp429RetryBaseDelay?: number |
Member
There was a problem hiding this comment.
I suggest removing the option and leaving only the constant value. In my opinion, there is no reason for a new option.
| log.warn(msg) | ||
| log.info(`Retrying ${retryCount}/${totalRetryCount}`) | ||
|
|
||
| const exp429RetryBaseDelay = fullRequestOptions.exp429RetryBaseDelay |
Member
There was a problem hiding this comment.
I suggest changing the name of this variable it's too complicated
| log.info(`Retrying ${retryCount}/${totalRetryCount}`) | ||
|
|
||
| const exp429RetryBaseDelay = fullRequestOptions.exp429RetryBaseDelay | ||
| if (exp429RetryBaseDelay && !(response instanceof Error) && response.statusCode === 429) { |
Member
There was a problem hiding this comment.
why are we here retraying absolutely all requests, not just for creating a session?
| const exp429RetryBaseDelay = fullRequestOptions.exp429RetryBaseDelay | ||
| if (exp429RetryBaseDelay && !(response instanceof Error) && response.statusCode === 429) { | ||
| const delay = Math.round(exp429RetryBaseDelay * 2 ** (retryCount - 1) + Math.random() * 100) | ||
| log.warn(`Session creation failed with 429, retrying in ${delay}ms`) |
Member
There was a problem hiding this comment.
Are you sure we need a warning here, not a debug log?
|
|
||
| const exp429RetryBaseDelay = fullRequestOptions.exp429RetryBaseDelay | ||
| if (exp429RetryBaseDelay && !(response instanceof Error) && response.statusCode === 429) { | ||
| const delay = Math.round(exp429RetryBaseDelay * 2 ** (retryCount - 1) + Math.random() * 100) |
Member
There was a problem hiding this comment.
why is the jitter so low? Only 100ms
| const delay = Math.round(exp429RetryBaseDelay * 2 ** (retryCount - 1) + Math.random() * 100) | ||
| log.warn(`Session creation failed with 429, retrying in ${delay}ms`) | ||
| return new Promise(resolve => setTimeout(resolve, delay)).then( | ||
| () => this._request(fullRequestOptions, transformResponse, customWdRequestAgent, totalRetryCount, retryCount) |
Member
There was a problem hiding this comment.
why not just delete this call and use the call of this._request below?
Author
There was a problem hiding this comment.
I used here timeout and it was more easy to implement
Member
There was a problem hiding this comment.
I used here timeout and it was more easy to implement
I don't understand why is code duplication easier to implement?
In my opinion, it is more correct to call the method once, especially if it has 4 parameters.
| return new Promise(resolve => setTimeout(resolve, delay)).then( | ||
| () => this._request(fullRequestOptions, transformResponse, customWdRequestAgent, totalRetryCount, retryCount) | ||
| ) | ||
| } |
Member
There was a problem hiding this comment.
what if tomorrow we let the user manage connectionRetryCount option? And he set value 10. How much we should wait? I'm saying that we need some kind of maximum limit.
Author
There was a problem hiding this comment.
We set this on testplane side, and maybe we have to set max limit there and do it when we provide it to config for users?
Member
There was a problem hiding this comment.
usually, when implementing retires logic, jitter and the maximum limit are always used
sonic16x
force-pushed
the
add-exp-429-retry
branch
from
August 12, 2026 10:23
1389b4f to
d642e9a
Compare
added 3 commits
August 13, 2026 18:39
DudaGod
approved these changes
Aug 14, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When a WebDriver grid responds with 429 (Too Many Requests) during, retries now use exponential backoff instead of hammering the server immediately.
Retry delays follow the formula
5000 × 2^attempt + jitter(0..1000ms), giving approximately 5s → 10s → 20s between attempts.The number of retries is controlled by the existing
connectionRetryCountoption.The backoff applies only to all requests which get 429.