re-enable as soon as the new Docker image is on DockerHub.
Bumping the docker Python dependency requires a synchronized update of LS, ext, and the Docker image on DockerHub. The current CLI tests use the latest image from DockerHub.

The update of docker adds a new platform flag and running this test against an old localstack image yields the error TypeError: run() got an unexpected keyword argument 'platform' (not visible in CI). Locally building a new LS Docker image via make docker-build fixes the issue.

good catch 👍

I think we're nearing the point where we should start writing an abstraction to generate these messages 🤔

(please not in this PR though 😁 )

fully agree 👍

@dominikschubert @joe4dev FYI there's a module in ASF that uses botocore for server-side validation, which does validation of constraints that are defined in the spec automatically (the first condition for example is in the spec, the second also): https://github.com/localstack/localstack/blob/master/localstack/aws/protocol/validate.py
the two problems are: defining the conditions that aren't in the spec (easy), and generalizing message creation (hard).
the messages are generally different across services, but some services definitely use the same pattern that we could generalize (i'm assuming there's some internal AWS library for matching constraints). that should definitely go into ASF :-)

we haven't invested in this yet really because in most cases, client-side validation will already take care of anything that's in the spec. so the cases where we would really benefit from this type of validation are fairly rare.

that should definitely go into ASF :-)

For schema-related things, I agree.

For non-schema validations I think this doesn't make much sense looking at the actual behavior and output we observe from AWS. From what I've seen so far this really is completely service-dependent and even in a single service doesn't always behave in a completely generalizable manner. You often also need service-internal state for these validations.
I'm not 100% sure that we can "cleanly" separate these two though, because I'm not sure they are cleanly separated on the side of AWS as well 😬

Some of the newer services that mostly just have CRUD API might be pretty standard though 🤔

@thrau Thank you for the pointer. I discussed this a few weeks ago with @dominikschubert but I wasn't aware the validation patterns are in the specs 👍

The mandatory fields are easier to generalize than the optional fields. In the "CreateFunction" operation there are only 3 required_members in the input shape out of 23 members. It often requires service-specific conditionals (sometimes based on service-internal state) to enable these validations.
Hence, this might require some service-specific ASF extension because the types in the request handler (i.e., @handler) are not compatible with the validation API (or I need to understand the validation API better) 🤔

As a quick POC: I can retrieve the correct model but it doesn't raise a validation error for the enum value set (would need to investigate inputs API better):

  service = load_service("lambda")
  operation = service.operation_model("CreateFunction")
  shape = operation.input_shape.members["Architectures"].member
  invalid_architecture = "x42"
  validation_errors = ParamValidator().validate(invalid_architecture, shape)

@thrau I discussed with @dominikschubert that we plan to pick up validations in a later polishing step as there are currently more urgent things to finalize.

@thrau I finally gave boto-spec-based validation another quick try with the many Lambda runtime updates slowing us down but it didn't really work:

from localstack.aws.protocol.validate import ParamValidator
from localstack.aws.spec import load_service

service = load_service("lambda")
operation = service.operation_model("CreateFunction")
shape = operation.input_shape.members["Runtime"]
invalid_runtime = "python3.10777"
validation_errors = ParamValidator().validate(invalid_runtime, shape)

print(str(validation_errors))

Nevertheless, I had to abort the idea because the snapshots revealed that the ordering was inconsistent (2 different orders within the Lambda API) and could not be reconstructed using boto-spec-based validation.

I mitigated the problem by re-organizing everything around Lambda runtimes in #9697 to facilitate future updates 🚀