SelectObjectContent ScanRange does not accept zero-start

[Licht-T]

Describe the bug

ScanRange is the zero-start range, but Rust SDK doesn't accept zero as Start value.

aws-sdk-rust/sdk/s3/src/xml_ser.rs

Lines 1114 to 1121 in b06cd25

	if input.start != 0 {
	let mut inner_writer = scope.start_el("Start").finish();
	inner_writer.data(aws_smithy_types::primitive::Encoder::from(input.start).encode());
	}
	if input.end != 0 {
	let mut inner_writer = scope.start_el("End").finish();
	inner_writer.data(aws_smithy_types::primitive::Encoder::from(input.end).encode());
	}

Expected Behavior

When the range is [0, 54], the ScanRange element of request body should be:

<ScanRange><Start>0</Start><End>54</End></ScanRange>

Current Behavior

When the range is [0, 54], it is currently:

<ScanRange><End>54</End></ScanRange>

Reproduction Steps

                    let mut select_object_content_req = client
                        .select_object_content()
                        .bucket(bucket.to_owned())
                        .key(key.to_owned())
(snip)
                        .scan_range(
                            ScanRange::builder()
                                .start(0)
                                .end(54)
                                .build(),
                        )

Possible Solution

No response

Additional Information/Context

No response

Version

v0.49.0

Environment details (OS name and version, etc.)

Ubuntu 22.04

Logs

No response

[Velfi]

@Licht-T Thanks for reporting this. I'll take a look today and see if I can fix it.

[Velfi]

I was able to reproduce this issue. It should be solvable by customizing the serializer to serialize zeros for that operation. Working on that now.

[Velfi]

I was able to fix this with a serializer codegen update. I'll update this post again once the fix is released (should be less than 2 weeks.)

[Licht-T]

Thanks, @Velfi. Looking forward to the PR merged.

[Velfi]

It looks like this is going to take longer than I expected. I'm going to be working this week to find a better solution to this issue.

[Velfi]

Hey @Licht-T, I'm sorry to say that there's been no new developments. My current stance is that I should probably close the current PR and create a new fix that solves this issue with input tracking, per @jdisanti 's comment.

[Velfi]

Sorry again for the lack of movement on this. This week I'm going to check if a recent PR that changes how we handle values like StartRange and EndRange fixes this.

[Velfi]

After looking into this, I believe it's going to be blocked until we implement smithy IDL v2 support. This is due to the fact that we need to interact with the default trait which is only available in IDL v2.

[Velfi]

Blocked on #536 and smithy-lang/smithy-rs#1767

[rcoh]

This should be fixed when S3 adds @clientOptional to all primitives.

[rcoh]

This should be fixed in v0.38, we are verifying

[jdisanti]

Confirmed this is fixed in the 1.x SDK version.

[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.