CLDSRV-918: raise SDK request timeout in functional test client#6187
CLDSRV-918: raise SDK request timeout in functional test client#6187tcarmet wants to merge 1 commit into
Conversation
Hello tcarmet,My role is to assist you with the merge of this Available options
Available commands
Status report is not available. |
Incorrect fix versionThe
Considering where you are trying to merge, I ignored possible hotfix versions and I expected to find:
Please check the |
❌ 229 Tests Failed:
View the top 3 failed test(s) by shortest run time
View the full list of 214 ❄️ flaky test(s)
To view more test analytics, go to the Test Analytics Dashboard |
|
LGTM |
Request integration branchesWaiting for integration branch creation to be requested by the user. To request integration branches, please comment on this pull request with the following command: Alternatively, the |
|
LGTM |
The SDK v2 test config set no timeout, so all tests ran with the v2 default of 120s (aws-sdk lib/config.js httpOptions.timeout). The v3 migration introduced a 5s requestTimeout, which heavy server-side operations (multi-megabyte UploadPartCopy, 1000-key batch deletes) exceed under CI load since the server sends no response bytes until they complete. Raise it to 30s: enough headroom for heavy operations, while staying below mocha's 40s global timeout so a genuine hang still surfaces as the SDK TimeoutError.
28c72f9 to
f908622
Compare
|
LGTM |
The AWS SDK v3 migration introduced a 5-second request timeout in the functional test client where SDK v2 previously ran with its 120-second default. Test operations that get no response bytes until the server finishes working - a 50MB server-side part copy, 1000-key batch deletes - regularly exceed 5 seconds of socket silence under CI load, producing
Connection timed out after 5000 msfailures on more than a dozen unrelated branches over the past 60 days, including one merge-queue hit.Raising the timeout to 30 seconds restores the pre-migration behavior within mocha's 40-second global cap: a genuine hang still fails the test, surfacing as the SDK's informative
TimeoutErrorinstead of a generic mocha timeout.Reference for the previous 120s behavior:
aws-sdk@2.1692.0shipshttpOptions: { timeout: 120000 }(lib/config.js#L626-L628), documented as "Sets the socket to timeout after timeout milliseconds of inactivity on the socket. Defaults to two minutes (120000)" (AWS.Config docs).tests/functional/aws-node-sdk/test/support/config.jsatea4659029configured no timeout at all, so every functional test ran with the 120s default.