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
added awsRequest for aws-sdk call backoff and retry in customResources #8338
Conversation
Codecov Report
@@ Coverage Diff @@
## master #8338 +/- ##
==========================================
+ Coverage 88.01% 88.15% +0.13%
==========================================
Files 249 249
Lines 9305 9300 -5
==========================================
+ Hits 8190 8198 +8
+ Misses 1115 1102 -13
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pratik-vii thanks for giving it a spin.
In given form this change is not effective. Note, that no custom resource logic was configured to new utility. We need to ensure that all of the functions rely on this utility, instead of invoking aws-sdk
directly.
Also this implementation does not look complete. I believe serviceInstance
needs to be resolved on spot, as it's here: https://github.com/serverless/test/blob/7dfc92e1d0d93c91f1c9affc872afa41fcb1c89b/aws-request.js
I was planning to integrate it once signature is approved, I had doubt to whether to keep
Sure. Will do. I was thinking of doing the same pattern, but I thought to give responsibility of configuring the |
…o aws-request-util
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @pratik-vii for update. It looks way better now.
Please see my comments. Also please test it by running integration tests, it's the only way to confirm, we did not break anything with this refactor
const apiGateway = new ApiGateway({ region }); | ||
const assignedRoleArn = (await apiGateway.getAccount().promise()).cloudwatchRoleArn; | ||
const assignedRoleArn = ( | ||
await awsRequest({ name: 'APIGateway', params: { region } }, 'getAccount').promise() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
awsRequest
should return promise directly, there should be no need for promise()
} | ||
); | ||
|
||
function awsRequest(service, method, ...args) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's use async/await
@@ -1,5 +1,7 @@ | |||
'use strict'; | |||
|
|||
const AWS = require('aws-sdk'); | |||
const _ = require('lodash'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should not introduce any dependencies here (note this is packaged for lambda, and we want to avoid npm install
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah. Will remove the usage of lodash
.
- changed awsRequest to async - removed unnecessary promise in awsRequest
@medikoo Thanks for the feedback. I have updated the PR,
I have tested the changes with dependent integration testcases |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @pratik-vii , that looks very good! I have just few minor suggestions. Let me know what you think
// temporary state where just created AWS role is not being ready for use (yet) | ||
await wait(10000); | ||
return updateAccount(++counter); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need to keep that try/catch, as in this case we want to catch also non-retryable errors, while awsRequest
retries only if error is retryable
requestTry < MAX_AWS_REQUEST_TRY && | ||
error && | ||
(error.statusCode === 429 || | ||
(error.retryable && error.statusCode !== 403 && error.code !== 'CredentialsError')) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can limit this to (error.statusCode === 429 || error.retryable)
, as in Lambda we should not expect credential errors, so it's not the case to consider
(error.statusCode === 429 || | ||
(error.retryable && error.statusCode !== 403 && error.code !== 'CredentialsError')) | ||
) { | ||
return wait(4000 + Math.random() * 3000).then(() => callAws(++requestTry)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
7 seconds, is a lot in lambda, let's make it maybe 2000 + Math.random() * 1000
, and maybe increase DEFAULT_MAX_AWS_REQUEST_TRY
to 8
const callAws = requestTry => { | ||
return serviceInstance[method](...args) | ||
.promise() | ||
.then( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's use async/await
- changed backoff time to (2000 + Math.random() * 1000)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank youi @pratik-vii ! That looks great
Closes: #8333