Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MediaConvert validation issue #624

Closed
0xpablo opened this issue Oct 16, 2022 · 6 comments
Closed

MediaConvert validation issue #624

0xpablo opened this issue Oct 16, 2022 · 6 comments

Comments

@0xpablo
Copy link

0xpablo commented Oct 16, 2022

Describe the bug
MediaConvert_Shapes has introduced a regression when validating S3 destinations.
The validation pattern looks like this: ^s3:\\/\\/$ when it would previously look like this: ^s3:\\/\\/.

This means that only destinations that match "s3://" work, which is unexpected as destinations like this one "s3://bucket/folder/file" should be allowed.

I temporarily forked and undo those changes here.

I understand that the shapes are autogenerated from the go SDK. In the GO SDK's mediaconvert.json I can see this:

        "com.amazonaws.mediaconvert#__stringPatternS3": {
            "type": "string",
            "traits": {
                "smithy.api#pattern": "^s3:\\/\\/$"
            }
        },

The JS SDK seems to contain the right pattern. See here.

I assume this is a bug on the GO SDK, but I wanted to ask in case we are not applying validations as expected, as I'm not too familiar about the API generation.
I will also try opening an issue in the GO SDK, in the meantime, I wonder if we should patch the issue in soto.

Thank you

@adam-fowler
Copy link
Member

This seems to have been an issue for quite a while. I haven’t released a new version of Soto in a couple of months. I see you have added an issue to the aws-sdk-go-v2 repo. I’ll
be interested to see how they respond.

Given the response time has been variable in the past, It is dependent on the service team updating the model for their service. I am going to add a patch for this. I’m on holiday at the moment though so you’ll have to wait until I’m back on the 26th.

@0xpablo
Copy link
Author

0xpablo commented Oct 16, 2022

Thanks for the quick reply @adam-fowler. I'm in no hurry as I forked Soto to patch the issue and can work with that.

For me it's okay to wait until the root issue is fixed in the go SDK.

If you think this should be patched in Soto without waiting Amazon's reply let me know and I can try to help.

Thanks!

@adam-fowler
Copy link
Member

@adam-fowler
Copy link
Member

Fixed

@0xpablo
Copy link
Author

0xpablo commented Oct 27, 2022

Thanks a lot @adam-fowler. It's sad to see how hard it is to make these issues reach the appropriate Amazon team. Nice that there is a patching mechanism in Soto 🙂

@adam-fowler
Copy link
Member

@0xpablo the difficulty of accessing service teams, forced me to implement the patching mechanism.

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

No branches or pull requests

2 participants