lambda: AliasOptions and VersionOptions should not extend EventInvokeConfigOptions

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

[nija-at]

@iph -

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.

I have a follow up question about your statement here.

According to the CloudFormation documentation on EventInvokeConfig, updates to the FunctionName or the Qualifier attributes require replacement, i.e., recreates the underlying resource.
Can a CloudFormation user actually move the event invoke config from one qualifier to the other?

On the other hand, the lambda APIs have the UpdateFunctionEventInvokeConfig API separate from the PutFunctionEventInvokeConfig API that likely allows a user to do what you describe, i.e., point the event invoke config at a different qualifier on the same function.

[nija-at]

Summarizing the conversation with @iph over another channel

There is no 'state' stored in an event invoke config, so the Put API and the Update API are really the same thing.

[github-actions]

This issue has not received any attention in 1 year. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.