Skip to content

Unblock arsenal bumps on 9.3: realign replication tests for CRR ObjectMD refactor#6193

Draft
delthas wants to merge 2 commits into
development/9.3from
improvement/CLDSRV-929/fix-9-3-replication-md-ci
Draft

Unblock arsenal bumps on 9.3: realign replication tests for CRR ObjectMD refactor#6193
delthas wants to merge 2 commits into
development/9.3from
improvement/CLDSRV-929/fix-9-3-replication-md-ci

Conversation

@delthas

@delthas delthas commented Jun 18, 2026

Copy link
Copy Markdown
Contributor

What

Unblocks the development/9.3 line to consume arsenal 8.4.7 (it was pinned to 8.4.4 and would fail CI on any bump to >= 8.4.7). Bumps arsenal to 8.4.7 and realigns the replication tests to the new (backward-compatible) ObjectMD.replicationInfo shape.

Why

Arsenal PR scality/Arsenal#2627 ("Support multi-destination CRR", first released in 8.4.7; already consumed by 9.4 via #6172) reworked ObjectMD.replicationInfo:

  • single-destination fields (destination/role/storageClass/storageType/dataStoreVersionId) are now optional/deprecated in favor of per-backend values in backends[];
  • empty defaults changed '' -> undefined, and the top-level dataStoreVersionId is dropped.

This is backward-compatible — the API surface cloudserver consumes is unchanged and the build job passes. Only test expectations drift.

Changes

  • tests/unit/api/objectReplicationMD.js: realign expected replicationInfo to the 8.4.7 shape (deprecated fields undefined; no top-level dataStoreVersionId). Pure expectation update.
  • tests/functional/aws-node-sdk/test/bucket/putBucketReplication.js: remove three cases that asserted the old single-destination restriction (overlapping prefixes across destinations; multiple destination buckets). Under multi-destination CRR these configs are now accepted.
  • First commit is a Prettier-only reformat of the two touched files (legacy formatting), to satisfy the changed-files Prettier CI check; the second commit holds the bump + realignment.

Verification (local, against arsenal 8.4.7)

  • Full unit suite: 5097 passing, 0 failing.
  • putBucketReplication functional: 58 passing.
  • mpuVersion functional: 42 passing (the CI mongo-v1-ft InternalErrors did not reproduce in isolation — a cross-test cascade, not a regression).

⚠️ Draft — pending a product decision

Removing those 3 tests means 9.3 now accepts multi-destination replication configs it has no feature code to honor (multi-dest is implemented only on 9.4: #6172/#6178/#6179). Keeping this draft until the replication owner (maeldonn) confirms accepting-but-not-honoring such configs on 9.3 is acceptable.

Issue: CLDSRV-929

delthas added 2 commits June 18, 2026 16:58
Pure formatting pass (no logic change) on the test files touched by the
arsenal 8.4.7 realignment, so the prettier CI check (which runs on whole files
modified by the PR) passes. Isolating the reformat keeps the functional commit
reviewable.

Issue: CLDSRV-929
Adopt arsenal 8.4.7 on the 9.3 line (was 8.4.4) so it stops being frozen off
arsenal patches. The multi-destination CRR refactor (arsenal #2627, in 8.4.7)
made ObjectMD.replicationInfo's single-destination fields optional/deprecated:
empty defaults changed '' -> undefined, and the top-level dataStoreVersionId is
dropped in favor of per-backend values. This is backward-compatible (the API is
unchanged and the cloudserver build passes); only test expectations drift.

- tests/unit/api/objectReplicationMD.js: realign expected replicationInfo to the
  8.4.7 shape (deprecated fields undefined; no top-level dataStoreVersionId).
- tests/functional/aws-node-sdk/test/bucket/putBucketReplication.js: remove three
  cases that asserted the old single-destination restriction (overlapping
  prefixes across destinations; multiple destination buckets) — these configs are
  now accepted under multi-destination CRR.

Verified locally against 8.4.7: full unit suite green (5097 passing);
putBucketReplication functional 58 passing.

Issue: CLDSRV-929
@bert-e

bert-e commented Jun 18, 2026

Copy link
Copy Markdown
Contributor

Hello delthas,

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.

@bert-e

bert-e commented Jun 18, 2026

Copy link
Copy Markdown
Contributor

Request integration branches

Waiting for integration branch creation to be requested by the user.

To request integration branches, please comment on this pull request with the following command:

/create_integration_branches

Alternatively, the /approve and /create_pull_requests commands will automatically
create the integration branches.

@claude

claude Bot commented Jun 18, 2026

Copy link
Copy Markdown

LGTM

Review by Claude Code

@codecov

codecov Bot commented Jun 18, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 84.63%. Comparing base (101a039) to head (af12802).
✅ All tests successful. No failed tests found.

Additional details and impacted files

Impacted file tree graph

@@               Coverage Diff                @@
##           development/9.3    #6193   +/-   ##
================================================
  Coverage            84.63%   84.63%           
================================================
  Files                  206      206           
  Lines                13356    13356           
================================================
  Hits                 11304    11304           
  Misses                2052     2052           
Flag Coverage Δ
file-ft-tests 68.36% <ø> (ø)
kmip-ft-tests 28.31% <ø> (ø)
mongo-v0-ft-tests 69.57% <ø> (-0.06%) ⬇️
mongo-v1-ft-tests 69.61% <ø> (ø)
multiple-backend 36.80% <ø> (ø)
sur-tests 36.68% <ø> (ø)
sur-tests-inflights 37.69% <ø> (ø)
unit 70.52% <ø> (ø)
utapi-v2-tests 34.58% <ø> (ø)

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

🚀 New features to boost your workflow:
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

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.

2 participants