Skip to content

Refactor replicate object with async await - #2780

Open
SylvainSenechal wants to merge 3 commits into
development/9.5from
improvement/BB-803
Open

Refactor replicate object with async await#2780
SylvainSenechal wants to merge 3 commits into
development/9.5from
improvement/BB-803

Conversation

@SylvainSenechal

@SylvainSenechal SylvainSenechal commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

Issue: BB-803

Review hints :

  • The diff is hard to read on github because indentations changes are marked as a diff, in my code editor, when looking at the diff, the display is different and it is significantly easier to review
  • Reviewable commit by commit

Imo this refactor is super overdue and not so complicated to do.

Refactor replicate object with async await

  • Also updated the async parallel util function into async await
  • Also made minimal mandatory updates to MultipleBackend class, as this class inherits ReplicateObject

@bert-e

bert-e commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

Hello sylvainsenechal,

My role is to assist you with the merge of this
pull request. Please type @bert-e help to get information
on this process, or consult the user documentation.

Available options
name description privileged authored
/after_pull_request Wait for the given pull request id to be merged before continuing with the current one.
/bypass_author_approval Bypass the pull request author's approval
/bypass_build_status Bypass the build and test status
/bypass_commit_size Bypass the check on the size of the changeset TBA
/bypass_incompatible_branch Bypass the check on the source branch prefix
/bypass_jira_check Bypass the Jira issue check
/bypass_peer_approval Bypass the pull request peers' approval
/bypass_leader_approval Bypass the pull request leaders' approval
/approve Instruct Bert-E that the author has approved the pull request. ✍️
/create_pull_requests Allow the creation of integration pull requests.
/create_integration_branches Allow the creation of integration branches.
/no_octopus Prevent Wall-E from doing any octopus merge and use multiple consecutive merge instead
/unanimity Change review acceptance criteria from one reviewer at least to all reviewers
/wait Instruct Bert-E not to run until further notice.
Available commands
name description privileged
/help Print Bert-E's manual in the pull request.
/status Print Bert-E's current status in the pull request TBA
/clear Remove all comments from Bert-E from the history TBA
/retry Re-start a fresh build TBA
/build Re-start a fresh build TBA
/force_reset Delete integration branches & pull requests, and restart merge process from the beginning.
/reset Try to remove integration branches unless there are commits on them which do not appear on the source branch.

Status report is not available.

/**
* Runs an async task for each item in a collection, up to `limit` at a time.
* On error, no new tasks are started, but already-running tasks are awaited
* before the function resolves. Returns [firstError, results] so that callers

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Return the first error only : Keeping same behavior as before with mapLimitWaitPendingIfError.

Could've returned all errors as a list but not needed now and prefer to keep existing behavior.
Cannot aggregate errors neither, as we need to keep the original error to check its properties to determine if its retryable or not

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

but already-running tasks are awaited what happens if an error is triggered here ? Can make sense to stop new flows on error, but for the current one we can miss an error ?

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Ok I saw your comment. I'm not sure it's the right approach and we should return all errors ?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Mhh its replicating initial pre migration behavior, I think its fine anyways as replicateObject will try to delete all orphans as soon as a single error is found

Although maybe there is a question raised about reusability of this function, maybe its built to be too custom for replicateObject and should be more generic (return array of errors) ?

Comment thread lib/util/mapLimitWaitPendingIfError.js Outdated

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

refactored with async await, in the file runTaskWithConcurrency

@scality scality deleted a comment from bert-e Jul 23, 2026
@bert-e

bert-e commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

Waiting for approval

The following approvals are needed before I can proceed with the merge:

  • the author

  • 2 peers

@codecov

codecov Bot commented Jul 23, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 85.55556% with 39 lines in your changes missing coverage. Please review.
✅ Project coverage is 75.42%. Comparing base (1d77181) to head (6dd6d10).

Files with missing lines Patch % Lines
extensions/replication/tasks/ReplicateObject.js 88.17% 24 Missing ⚠️
...xtensions/replication/tasks/MultipleBackendTask.js 65.11% 15 Missing ⚠️
Additional details and impacted files

Impacted file tree graph

Files with missing lines Coverage Δ
lib/tasks/BackbeatTask.js 95.74% <100.00%> (+0.62%) ⬆️
lib/util/runTasksWithConcurrency.js 100.00% <100.00%> (ø)
...xtensions/replication/tasks/MultipleBackendTask.js 60.00% <65.11%> (-0.05%) ⬇️
extensions/replication/tasks/ReplicateObject.js 92.45% <88.17%> (+0.01%) ⬆️
Components Coverage Δ
Bucket Notification 80.27% <ø> (ø)
Core Library 81.20% <100.00%> (-0.02%) ⬇️
Ingestion 70.13% <ø> (ø)
Lifecycle 80.25% <ø> (ø)
Oplog Populator 85.83% <ø> (ø)
Replication 61.99% <84.14%> (+<0.01%) ⬆️
Bucket Scanner 85.76% <ø> (ø)
@@                 Coverage Diff                 @@
##           development/9.5    #2780      +/-   ##
===================================================
- Coverage            75.43%   75.42%   -0.01%     
===================================================
  Files                  201      201              
  Lines                13935    13934       -1     
===================================================
- Hits                 10512    10510       -2     
- Misses                3413     3414       +1     
  Partials                10       10              
Flag Coverage Δ
api:retry 9.05% <0.74%> (+<0.01%) ⬆️
api:routes 8.82% <0.00%> (+<0.01%) ⬆️
bucket-scanner 85.76% <ø> (ø)
ft_test:queuepopulator 9.13% <0.00%> (+<0.01%) ⬆️
ingestion 12.26% <0.00%> (+<0.01%) ⬆️
lib 8.77% <0.00%> (+<0.01%) ⬆️
lifecycle 19.23% <0.74%> (-0.01%) ⬇️
notification 1.02% <0.00%> (+<0.01%) ⬆️
oplogPopulator 0.13% <0.00%> (+<0.01%) ⬆️
replication 18.78% <78.14%> (-0.03%) ⬇️
unit 54.68% <54.44%> (+0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Comment thread extensions/replication/tasks/ReplicateObject.js
Comment thread extensions/replication/tasks/MultipleBackendTask.js Outdated
Comment thread extensions/replication/tasks/ReplicateObject.js
Comment thread extensions/replication/tasks/MultipleBackendTask.js

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Migrations here aren't the main point of this pr, but were kinda forced as MultipleBackend extends ReplicateObject.

I did the minimum required migration on this file

@SylvainSenechal
SylvainSenechal requested review from a team, benzekrimaha and delthas July 23, 2026 20:35
@SylvainSenechal
SylvainSenechal marked this pull request as ready for review July 23, 2026 20:35
@SylvainSenechal
SylvainSenechal requested review from maeldonn and removed request for delthas July 23, 2026 20:35

@benzekrimaha benzekrimaha left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Good refactor overall, but one real issue with the outcome handler being called from inside the try.

await this._deleteOrphans(destEntry, destLocations, log);
throw err;
}
return this._handleReplicationOutcome(null, sourceEntry, destEntry, kafkaEntry, log, done);

@benzekrimaha benzekrimaha Jul 24, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

_handleReplicationOutcome(null, …, done) is called from inside the try: if it throws after calling done, the catch calls it again and done fires twice. We can compute the error in the try/catch and call the handler exactly once after it. (same at line 909 and in _processQueueEntryRetryFull)

@bert-e

bert-e commented Jul 24, 2026

Copy link
Copy Markdown
Contributor

Waiting for approval

The following approvals are needed before I can proceed with the merge:

  • the author

  • 2 peers

The following reviewers are expecting changes from the author, or must review again:

@SylvainSenechal

Copy link
Copy Markdown
Contributor Author

Sorry I took some time to respond, you can review again next week @benzekrimaha @maeldonn

Comment thread extensions/replication/tasks/ReplicateObject.js Outdated
Comment thread extensions/replication/tasks/ReplicateObject.js Outdated
@maeldonn
maeldonn requested review from a team and DarkIsDude and removed request for maeldonn August 3, 2026 16:38

@DarkIsDude DarkIsDude left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Please try to create dedicated commit for prettier format as mention in the best practice of the migration 🙏. You can also use "Hide whitespace" on Github to ease diff if you want.

Image

CI is red, maybe you should have a look ?

// Sets up source clients using the role from the replication
// configuration if the authentication type is as such.
return this._setupRoles(entry, log, cb);
return this._setupRoles(entry, log).then(() => cb()).catch(cb);

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

This is always weird to read.

Suggested change
return this._setupRoles(entry, log).then(() => cb()).catch(cb);
return this._setupRoles(entry, log).then((_result) => cb()).catch(cb);

_ is a convention in JS for unused parameter. The linter should not complain, what do you think ? I guess this can be an error if the callback trigger an error ?

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

And I think we have the same issue here with .catch

@SylvainSenechal SylvainSenechal Aug 7, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

yeah its nicer to have _result, I also see i messed up some stuff around the catches, its tricky

edit : no : Error: 1190:51 error '_result' is defined but never used no-unused-vars

Comment thread lib/tasks/BackbeatTask.js Outdated
actionFunc(_handleRes, nbRetries);
}

retryAsync(args) {

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

We usually prefer to keep the function retry and the last argument (done) is optional ?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Yeah im moving this at the top of retry

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Did you get a try to some library to do that ?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I asked ai to create this function, although I also looked online at how people do it and the solutions were very similar.
Definitly there are libraries for this, but taking a look rapidly I only small non popular one, can't find a proper "do parallel stuff with js" thats very popular and battle tested.
Here we also have some specific behavior, about continuing ongoing task when one error is found, so not sure the available libraries would offer that.

I think its fine to not use a lib

/**
* Runs an async task for each item in a collection, up to `limit` at a time.
* On error, no new tasks are started, but already-running tasks are awaited
* before the function resolves. Returns [firstError, results] so that callers

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

but already-running tasks are awaited what happens if an error is triggered here ? Can make sense to stop new flows on error, but for the current one we can miss an error ?

const errors = [];

const worker = async () => {
while (nextIdx < coll.length) {

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Let say

  • A while (nextIdx < coll.length) {
  • B const idx = nextIdx++;

With 2 workers you can have A1 B1 A1 A2 B1 B2 and then trigger an error as coll is only size 2 ?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

no I think this is fine, its js single threaded code even if it kinda looks weird, this wont run at the same time 🤔

/**
* Runs an async task for each item in a collection, up to `limit` at a time.
* On error, no new tasks are started, but already-running tasks are awaited
* before the function resolves. Returns [firstError, results] so that callers

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Ok I saw your comment. I'm not sure it's the right approach and we should return all errors ?

outcome = err;
}
const result = await this._handleReplicationOutcome(outcome, sourceEntry, destEntry, kafkaEntry, log);
return result === null ? done() : done(null, result);

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

This is what we don't want to do in async migration. done should not be called inside the async function 🙏. We did a skill to ease migration (and a confluence page) where we explain the why

next => this._refreshSourceEntry(sourceEntry, log, (err, res) => {
if (err && err.name === 'ObjNotFound' &&
sourceEntry.getReplicationIsNFS() && !sourceEntry.getIsDeleteMarker()) {
next => this._refreshSourceEntry(sourceEntry, log)

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

This will runs the next waterfall stage synchronously, and that stage is not async — metricsHandler.rpo() can all throw synchronously for example. A throw there lands in .catch, which calls next again; async.waterfall's onlyOnce then throws "Callback was already called" as an uncaught exception in the queue processor, masking the real error. Use the two-argument then so the success path can't feed the rejection handler

next => this._refreshSourceEntry(sourceEntry, log)
                .then(res => next(null, res), err => {

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

aiya its more complicated than i thought to make these refactoring

@bert-e

bert-e commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

Waiting for approval

The following approvals are needed before I can proceed with the merge:

  • the author

  • 2 peers

The following reviewers are expecting changes from the author, or must review again:

@SylvainSenechal
SylvainSenechal force-pushed the improvement/BB-803 branch 2 times, most recently from 449cafe to 05fd0ff Compare August 7, 2026 12:57
@SylvainSenechal

Copy link
Copy Markdown
Contributor Author

Please try to create dedicated commit for prettier format as mention in the best practice of the migration 🙏. You can also use "Hide whitespace" on Github to ease diff if you want.

Image CI is red, maybe you should have a look ?

I didnt run the linter though, the diff is just re indentation mostly 🤔
The failure were unrelated, its rerunning but it was fine the other time so should be good here

Comment thread extensions/replication/tasks/ReplicateObject.js
Comment thread extensions/replication/tasks/ReplicateObject.js Outdated
this commit is mandatory as multipleBackend is a class that extends replicateObject and some functions are overloaded

Issue: BB-803
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants