Skip to content

lambda: AliasOptions and VersionOptions should not extend EventInvokeConfigOptions #6966

@eladb

Description

@eladb

In v2.0 we should change the way we model event invoke configuration in AWS Lambda.

Originally posted by @iph in #6771

This was already there but since we are changing it to AliasOptions, it's strange to see EventInvokeConfigOptions as the base object here, as the two are two separate objects in cfn. Technically an alias can have an event invoke config and there is no mixin for typescript (unsure, I'm new to the language) so this was the best way? It seems brittle to tie that together because there will be additional concepts. Are we going to have multi-extends clauses per concept that is added to a qualifier that aliases supports? Will that work with JSII?

To me, it's about the degree of freedom. The kind of object relationship looks more like this:

                            event invoke config
                            -------------------
                                retries: 1
                                success: sqs ---+
                                                |
                                                |
Alias    develop      gamma         live <------+
             |         |              |
             |         |              |
Version: $LATEST------ v3-------------v2 ....
             |
         function:
           code +     code +         code +
           config     config         config

An event config you can move freely from the underlying version/alias. This is super awesome because we've seen customers who accidentally create a like million message async invoke backlog, and event invoke config is a way to drain the backlog rapidly. If we were to put that object onto a version, which is immutable, then a customer would have to override their deployment systems to move the alias for "live" extremely forward in time to $LATEST potentially.

Again, it's technically correct today: all options in event invoke config are optional and you can attach an event invoke config to an alias, so this works out. The two, over time, will diverge in responsibilities due to their degrees of freedom that Lambda team intentionally decided to separate at an object level and it sparks a saddened emotion to see them tied together.

Metadata

Metadata

Assignees

No one assigned

    Labels

    @aws-cdk/aws-lambdaRelated to AWS Lambdaclosed-for-stalenessThis issue was automatically closed because it hadn't received any attention in a while.effort/mediumMedium work item – several days of effortfeature-requestA feature should be added or improved.p1

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions