Setting s3 public access block configuration fails when all options are false

[RobbieClarken]

Describe the bug

When using the S3 put_public_access_block method, if all four options options are set to false the request will fail. For example:

use aws_sdk_s3 as s3;

#[tokio::main]
#[allow(clippy::result_large_err)]
async fn main() -> Result<(), s3::Error> {
    let region = "us-east-1";
    let bucket = "CHANGE_ME";
    let config = aws_config::from_env().load().await;
    let client = s3::Client::new(&config);
    client
        .create_bucket()
        .bucket(bucket)
        .create_bucket_configuration(
            s3::types::CreateBucketConfiguration::builder()
                .location_constraint(s3::types::BucketLocationConstraint::from(region))
                .build(),
        )
        .send()
        .await?;
    client
        .put_public_access_block()
        .bucket(bucket)
        .public_access_block_configuration(
            s3::types::PublicAccessBlockConfiguration::builder()
                .block_public_acls(false) // <-------- setting all four options to false triggers the bug
                .ignore_public_acls(false) // <-------
                .block_public_policy(false) // <------
                .restrict_public_buckets(false) // <--
                .build(),
        )
        .send()
        .await?;
    Ok(())
}

If at least one of four PublicAccessBlockConfiguration options is set to true then the request will succeed.

Expected Behavior

Running the code above should not produce any errors and result in these options all being disabled for the S3 bucket:

Current Behavior

The code above produces an error:

Error: Unhandled(Unhandled { source: ErrorMetadata { code: Some("InvalidRequest"), message: Some("Must specify at least one configuration."), extras: Some({"s3_extended_request_id": "7VTi3scszh1zFOtXoEMM6NXIjKaSvbsV7yu9l5ECtcJOuaH0PPwaRnEmVwNXgYtZI2URi1FiwVE=", "aws_request_id": "Q2AZ3BYQM6EYQC3Y"}) }, meta: ErrorMetadata { code: Some("InvalidRequest"), message: Some("Must specify at least one configuration."), extras: Some({"s3_extended_request_id": "7VTi3scszh1zFOtXoEMM6NXIjKaSvbsV7yu9l5ECtcJOuaH0PPwaRnEmVwNXgYtZI2URi1FiwVE=", "aws_request_id": "Q2AZ3BYQM6EYQC3Y"}) } })

Reproduction Steps

Run the code above (after changing bucket to an unused S3 bucket name).

Possible Solution

I believe the problem is due to the ser_public_access_block_configuration function having if conditions which skips serializing the options that are false. This function should probably just output the options irrespective of whether they are true or false.

Additional Information/Context

To confirm it is valid to make a request where all 4 options are false you can run the following aws-cli command:

aws s3api put-public-access-block --bucket CHANGE_ME --public-access-block-configuration 'BlockPublicAcls=false,IgnorePublicAcls=false,BlockPublicPolicy=false,RestrictPublicBuckets=false'

Version

├── aws-config v0.55.3
│   ├── aws-credential-types v0.55.3
│   │   ├── aws-smithy-async v0.55.3
│   │   ├── aws-smithy-types v0.55.3
│   ├── aws-http v0.55.3
│   │   ├── aws-credential-types v0.55.3 (*)
│   │   ├── aws-smithy-http v0.55.3
│   │   │   ├── aws-smithy-eventstream v0.55.3
│   │   │   │   ├── aws-smithy-types v0.55.3 (*)
│   │   │   ├── aws-smithy-types v0.55.3 (*)
│   │   ├── aws-smithy-types v0.55.3 (*)
│   │   ├── aws-types v0.55.3
│   │   │   ├── aws-credential-types v0.55.3 (*)
│   │   │   ├── aws-smithy-async v0.55.3 (*)
│   │   │   ├── aws-smithy-client v0.55.3
│   │   │   │   ├── aws-smithy-async v0.55.3 (*)
│   │   │   │   ├── aws-smithy-http v0.55.3 (*)
│   │   │   │   ├── aws-smithy-http-tower v0.55.3
│   │   │   │   │   ├── aws-smithy-http v0.55.3 (*)
│   │   │   │   │   ├── aws-smithy-types v0.55.3 (*)
│   │   │   │   ├── aws-smithy-types v0.55.3 (*)
│   │   │   ├── aws-smithy-http v0.55.3 (*)
│   │   │   ├── aws-smithy-types v0.55.3 (*)
│   ├── aws-sdk-sso v0.28.0
│   │   ├── aws-credential-types v0.55.3 (*)
│   │   ├── aws-endpoint v0.55.3
│   │   │   ├── aws-smithy-http v0.55.3 (*)
│   │   │   ├── aws-smithy-types v0.55.3 (*)
│   │   │   ├── aws-types v0.55.3 (*)
│   │   ├── aws-http v0.55.3 (*)
│   │   ├── aws-sig-auth v0.55.3
│   │   │   ├── aws-credential-types v0.55.3 (*)
│   │   │   ├── aws-sigv4 v0.55.3
│   │   │   │   ├── aws-smithy-eventstream v0.55.3 (*)
│   │   │   │   ├── aws-smithy-http v0.55.3 (*)
│   │   │   ├── aws-smithy-eventstream v0.55.3 (*)
│   │   │   ├── aws-smithy-http v0.55.3 (*)
│   │   │   ├── aws-types v0.55.3 (*)
│   │   ├── aws-smithy-async v0.55.3 (*)
│   │   ├── aws-smithy-client v0.55.3 (*)
│   │   ├── aws-smithy-http v0.55.3 (*)
│   │   ├── aws-smithy-http-tower v0.55.3 (*)
│   │   ├── aws-smithy-json v0.55.3
│   │   │   └── aws-smithy-types v0.55.3 (*)
│   │   ├── aws-smithy-types v0.55.3 (*)
│   │   ├── aws-types v0.55.3 (*)
│   ├── aws-sdk-sts v0.28.0
│   │   ├── aws-credential-types v0.55.3 (*)
│   │   ├── aws-endpoint v0.55.3 (*)
│   │   ├── aws-http v0.55.3 (*)
│   │   ├── aws-sig-auth v0.55.3 (*)
│   │   ├── aws-smithy-async v0.55.3 (*)
│   │   ├── aws-smithy-client v0.55.3 (*)
│   │   ├── aws-smithy-http v0.55.3 (*)
│   │   ├── aws-smithy-http-tower v0.55.3 (*)
│   │   ├── aws-smithy-json v0.55.3 (*)
│   │   ├── aws-smithy-query v0.55.3
│   │   │   ├── aws-smithy-types v0.55.3 (*)
│   │   ├── aws-smithy-types v0.55.3 (*)
│   │   ├── aws-smithy-xml v0.55.3
│   │   ├── aws-types v0.55.3 (*)
│   ├── aws-smithy-async v0.55.3 (*)
│   ├── aws-smithy-client v0.55.3 (*)
│   ├── aws-smithy-http v0.55.3 (*)
│   ├── aws-smithy-http-tower v0.55.3 (*)
│   ├── aws-smithy-json v0.55.3 (*)
│   ├── aws-smithy-types v0.55.3 (*)
│   ├── aws-types v0.55.3 (*)
├── aws-sdk-s3 v0.28.0
│   ├── aws-credential-types v0.55.3 (*)
│   ├── aws-endpoint v0.55.3 (*)
│   ├── aws-http v0.55.3 (*)
│   ├── aws-sig-auth v0.55.3 (*)
│   ├── aws-sigv4 v0.55.3 (*)
│   ├── aws-smithy-async v0.55.3 (*)
│   ├── aws-smithy-checksums v0.55.3
│   │   ├── aws-smithy-http v0.55.3 (*)
│   │   ├── aws-smithy-types v0.55.3 (*)
│   ├── aws-smithy-client v0.55.3 (*)
│   ├── aws-smithy-eventstream v0.55.3 (*)
│   ├── aws-smithy-http v0.55.3 (*)
│   ├── aws-smithy-http-tower v0.55.3 (*)
│   ├── aws-smithy-json v0.55.3 (*)
│   ├── aws-smithy-types v0.55.3 (*)
│   ├── aws-smithy-xml v0.55.3 (*)
│   ├── aws-types v0.55.3 (*)

### Environment details (OS name and version, etc.)

macOS 12.5.1, rustc 1.71.0-nightly

### Logs

_No response_

[RobbieClarken]

A workaround is to use the delete_public_access_block method:

client
    .delete_public_access_block()
    .bucket(bucket)
    .send()
    .await?;

[Velfi]

@RobbieClarken thanks for submitting such a well-written issue report. I've seen similar failures with S3 APIs that have funky handling of default values. S3 seems to often treat null and false as different values, which leads to stuff like this.

To whomever is tasked with fixing this:

• We should look into how other SDKs are handling this.

[rcoh]

This issue occurs because the S3 model incorrectly marks these fields as required when they are optional. We need to either wait for the updated S3 model or add a customization on our side to automatically apply the clientOptionalTrait

[rcoh]

Sorry for the delay. This issue should be fixed in v0.38

[jmklix]

Testing this in the latest version and it now work without any errors. Closing this issue

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.