MediaConvert validation issue

[0xpablo]

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]

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]

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]

630 and https://github.com/soto-project/soto-codegenerator/commit/46d35fbda5c737d142a583be2e7091abdda2680a

[adam-fowler]

Fixed

[0xpablo]

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]

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