Skip to content

Conversation

@DarkIsDude
Copy link
Contributor

@DarkIsDude DarkIsDude commented Dec 17, 2025

Pull request template

Description

Support a new header x-amz-object-optional-attributes to be able to retrieve in the ListObjectsV2 user metadata.

Motivation and context

https://github.com/scality/citadel/pull/301/changes

https://scality.atlassian.net/browse/CLDSRV-812

Related issues

scality/Arsenal#2581 is needed as the bump of Arsenal in Vault.

A new MR will be opened to update the response of ListObjectsV2 and return asked fields.

@DarkIsDude DarkIsDude self-assigned this Dec 17, 2025
@bert-e
Copy link
Contributor

bert-e commented Dec 17, 2025

Hello darkisdude,

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
Copy link
Contributor

bert-e commented Dec 17, 2025

Incorrect fix version

The Fix Version/s in issue CLDSRV-812 contains:

  • None

Considering where you are trying to merge, I ignored possible hotfix versions and I expected to find:

  • 9.2.11

Please check the Fix Version/s of CLDSRV-812, or the target
branch of this pull request.

@codecov
Copy link

codecov bot commented Dec 17, 2025

Codecov Report

❌ Patch coverage is 92.30769% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 84.36%. Comparing base (c8fe018) to head (f626fcb).
⚠️ Report is 21 commits behind head on development/9.2.
✅ All tests successful. No failed tests found.

Files with missing lines Patch % Lines
lib/api/bucketGet.js 85.71% 1 Missing ⚠️
Additional details and impacted files

Impacted file tree graph

Files with missing lines Coverage Δ
...i/apiUtils/authorization/prepareRequestContexts.js 95.34% <100.00%> (+0.22%) ⬆️
lib/api/bucketGet.js 96.24% <85.71%> (+0.08%) ⬆️
@@                 Coverage Diff                 @@
##           development/9.2    #6033      +/-   ##
===================================================
+ Coverage            84.34%   84.36%   +0.01%     
===================================================
  Files                  204      204              
  Lines                12926    12935       +9     
===================================================
+ Hits                 10903    10912       +9     
  Misses                2023     2023              
Flag Coverage Δ
file-ft-tests 67.44% <76.92%> (+<0.01%) ⬆️
kmip-ft-tests 28.13% <0.00%> (-0.02%) ⬇️
mongo-v0-ft-tests 68.69% <76.92%> (+<0.01%) ⬆️
mongo-v1-ft-tests 68.68% <76.92%> (+<0.01%) ⬆️
multiple-backend 35.35% <69.23%> (+0.02%) ⬆️
sur-tests 35.67% <69.23%> (+0.02%) ⬆️
sur-tests-inflights 37.49% <69.23%> (-0.01%) ⬇️
unit 69.94% <92.30%> (+0.02%) ⬆️
utapi-v2-tests 34.37% <69.23%> (+0.03%) ⬆️

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.

@bert-e
Copy link
Contributor

bert-e commented Dec 18, 2025

Incorrect fix version

The Fix Version/s in issue CLDSRV-812 contains:

  • None

Considering where you are trying to merge, I ignored possible hotfix versions and I expected to find:

  • 9.2.12

Please check the Fix Version/s of CLDSRV-812, or the target
branch of this pull request.

@DarkIsDude DarkIsDude requested review from a team, SylvainSenechal and delthas December 18, 2025 16:39
@bert-e
Copy link
Contributor

bert-e commented Dec 18, 2025

Waiting for approval

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

  • the author

  • 2 peers

@DarkIsDude DarkIsDude marked this pull request as ready for review December 19, 2025 09:09
});

it('should ignore the missing permission if the header contains only RestoreStatus', done => {
const testGetRequest = Object.assign({
Copy link
Contributor

@francoisferrand francoisferrand Jan 9, 2026

Choose a reason for hiding this comment

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

while we should have a test with this purpose, looking at the code I think it does not really test anything: permission-wise, we have the exact same test as should return valid xml if the user have the permission (the only difference between the tests is the attribute we ask for, but no difference in "auth" setup/mock or assertion on the requested permissions)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The idea of tests is to tests each "path" of the code. Here we have 2 differents cases (coming from product) that I'm trying to reflect in the code. If you have the permission, then you can ask for user metadata, if not, you should be able to request only RestoreStatus. So even the result is the same, the code path is not the same and we test this condition if (requestedAttributes.filter(attr => attr != 'RestoreStatus').length > 0) {

Copy link
Contributor

Choose a reason for hiding this comment

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

Testing the different code path is fine (i.e. RestoreStatus vs x-amz-meta-department)

My issue is that the test mentions permissions, which is not tested at all in this test : i.e. we do not verify that the right permissions/actions were requested, use some mocks, [...] to ensure that the custom permission is not required in case only RestoreStatus is present...

(err, result) => {
assert.strictEqual(err, null);
assert.strictEqual(result.ListBucketResult.$.xmlns, 'http://s3.amazonaws.com/doc/2006-03-01/');
done();
Copy link
Contributor

Choose a reason for hiding this comment

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

as such, this test (and the next) do not test much : since we don't have a way to check that "every" requested field is returned

I guess this will be fixed in next PR, but may be best to add a //TODO for now to ensure we don't forget to update the test in next PR

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, in next PR I create new test as the logic tested is different and a test should test only one thing. Even if the result is the same, the logic tested here is to make sure that with several attributes, the GET is working and nothing break

Copy link
Contributor

@francoisferrand francoisferrand Jan 13, 2026

Choose a reason for hiding this comment

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

it does not test GET is working (only that it does not crash), as it does not validate which permissions are requested

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll add some spy to be sure then 👍

@bert-e
Copy link
Contributor

bert-e commented Jan 12, 2026

Incorrect fix version

The Fix Version/s in issue CLDSRV-812 contains:

  • 9.2.13

Considering where you are trying to merge, I ignored possible hotfix versions and I expected to find:

  • 9.2.15

  • 9.3.0

Please check the Fix Version/s of CLDSRV-812, or the target
branch of this pull request.

@bert-e
Copy link
Contributor

bert-e commented Jan 12, 2026

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.

const optionalAttributesHeader = request.headers['x-amz-optional-object-attributes'];
const requestedAttributes = optionalAttributesHeader ?
optionalAttributesHeader.split(',').map(
header => header !== 'RestoreStatus' ? header.toLowerCase() : header
Copy link
Contributor

Choose a reason for hiding this comment

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

If I understand correctly, the reason why RestoreStatus is not lower-cased is because of AWS standard ? why not leaving the other params the same ? Because we store them lower-cased ?

Copy link
Contributor

Choose a reason for hiding this comment

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

for what I understand, you added this since user metadata are expected to be lower case in AWS (did not check, but I think I saw you mention this). In that case,

  • what happens (on AWS) if an upper case metadata is used? It is rejected, just "converted" to lower case?
  • how does our API behave? If
  • Does this apply to the prefix (x-amz-meta-) as well? e.g. if we only consider lower case prefix, no need to convert to lower case for filtering user-metadata properties...

(overall, trying to say that we don't need to be too defensive here: if spec & API both only support lower user-metadata, no need to spend cycle trying to accomodate, we can just be strict and expect user to behave correctly)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Indeed, user metadata are lowercase. AWS will convert a non lowercase usermetadata to a lowercase (we are doing the same). And yes, this apply to the prefix also.

request.headers['x-amz-optional-object-attributes']?.split(',').map(attr => attr.trim()) ?? [];
if (optionalAttributes.some(attr => !attr.startsWith('x-amz-meta-') && attr != 'RestoreStatus')) {
return callback(
errorInstances.InvalidArgument.customizeDescription('Invalid header x-amz-optional-object-attributes')
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this the official aws error ? If so we can leave it, but if its a custom one that you choose, why not add the value of the problematic value

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch, the error returned by AWS is Invalid attribute name specified so I guess I must do the same 👏

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.

5 participants