-
Notifications
You must be signed in to change notification settings - Fork 255
🎨 Async/Await migration on bucketGet and objectGetLegalHold #6045
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
base: development/9.3
Are you sure you want to change the base?
Conversation
Hello darkisdude,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 |
Codecov Report❌ Patch coverage is
Additional details and impacted files
... and 1 file with indirect coverage changes @@ Coverage Diff @@
## development/9.3 #6045 +/- ##
===================================================
- Coverage 84.44% 84.43% -0.02%
===================================================
Files 206 206
Lines 13186 13205 +19
===================================================
+ Hits 11135 11149 +14
- Misses 2051 2056 +5
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
16402cf to
4e7d644
Compare
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 |
Incorrect fix versionThe
Considering where you are trying to merge, I ignored possible hotfix versions and I expected to find:
Please check the |
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 |
Incorrect fix versionThe
Considering where you are trying to merge, I ignored possible hotfix versions and I expected to find:
Please check the |
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 |
bafa722 to
08d8dc0
Compare
Incorrect fix versionThe
Considering where you are trying to merge, I ignored possible hotfix versions and I expected to find:
Please check the |
474bad8 to
7a14efc
Compare
7a14efc to
c98d577
Compare
c98d577 to
4f6b182
Compare
d6342e9 to
7559941
Compare
7559941 to
99b9108
Compare
872cfa3 to
7bed447
Compare
ConflictThere is a conflict between your branch Please resolve the conflict on the feature branch ( git fetch && \
git checkout origin/feature/CLDSRV-823/async-await-start && \
git merge origin/development/9.3Resolve merge conflicts and commit git push origin HEAD:feature/CLDSRV-823/async-await-start |
Issue: CLDSRV-823
7b03be0 to
b6e1ad0
Compare
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
|
| log.debug('error processing request', { err }); | ||
| monitoring.promMetrics('GET', bucketName, err.code, 'listBucket'); | ||
| throw err; | ||
| } |
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.
not an issue for this PR, but I wonder if we can write this "more cleanly" (e.g. avoid the separate let variable, and make the exception "wrapping" more seamless) with a combination of promise and await? e.g. something like this:
const bucket = await standardMetadataValidateBucketPromised(metadataValParams, request.actionImplicitDenies, log).catch(err => {
log.debug('error processing request', { err });
monitoring.promMetrics('GET', bucketName, err.code, 'listBucket');
throw err;
});(ideally, I'd rather avoid such "exception wrapping", but may not be possible in every case...)
what do you think: Does it work? Is there some Is this a "pattern" we may or should use?
or should we rather a single try/catch over the whole function in such case (which would avoid the duplicated "catch" block for log & prometheus)?
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.
That's a good question and it depends a lot on each case. I prefer for example the try/catch than the mix of promise/await but it's a pure personal opinion. IMO the industry try to move to a more try/catch approach but it's just a feeling. Anyway what you suggest should work.
It's a "migration". So some pattern can not be perfect... A good option to avoid the try/catch can be to type of errors and use that in one catch block (more or less what we did for AWS error). In that case I would suggest to keep the try/catch and don't try to complexify the migration. It's a well balanced between moving forward with the migration and improving our code.
| const verCfg = bucket.getVersioningConfiguration(); | ||
| additionalResHeaders['x-amz-version-id'] = getVersionIdResHeader(verCfg, objectMD); | ||
|
|
||
| return [xml, additionalResHeaders]; |
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 should explicitly add this corner-case in the TAD, to warn user when migrating functions which pass multiple values to callback?
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.
Issue: CLDSRV-823
Description
Motivation and context
Opening a first PR to migrate from callback to async/await syntax. A TAD is opened.
https://scality.atlassian.net/wiki/spaces/OS/pages/3523346468/2025-10-30+-+Async+Await+migration
This is a first PR to start the migration. As mention in the TAD, the idea is to migrate to async/await when working on a specific part of our component. Maybe a common goal of one PR per squad per sprint is a good idea.
All idea or remarks are welcome 🙏