Impossible to use dynamodb stream trigger with exported stream ARN and configValidationMode="error"

[LouisPinsard]

Description

Hello !

I am using lift 1.17.0 and serverless 3.17.0. I used the single table construct to deploy a dynamodb table and I am now trying to trigger a lambda function with the dynamodb stream of the table.

The event key for my function :

events: [
    {
      stream: {
        type: 'dynamodb',
        arn: '${construct:myTable.tableStreamArn}',
      },
    },
  ],
};

In my serverless configuration, I have configValidationMode: 'error',

I have the following error when deploying : Error: Configuration error at 'functions.dispatchEvents.events.0.stream': unsupported string format

It works well when I use configValidationMode: 'warn', the lambda and the trigger are well deployed and working

How to Reproduce

service: my-app
configValidationMode: error
provider:
    name: aws

plugins:
    - serverless-lift

functions:
    myFunc:
        handler: './handler.main'
        events:
            - stream:
                type: dynamodb
                arn: ${construct:myTable.tableStreamArn}

constructs:
    myTable:
        type: database/dynamodb-single-table

Additional Information

No response

[fredericbarthelet]

Thanks for reporting this issue @LouisPinsard :)

Digging around a little bit with your exemple serverless.yml, I've found out that at the time of Serverless Framework validation, the service definition input - or at least solely the myFunc.events[0].stream - passed into ajv validator has the following value { type: 'dynamodb', arn: '${Token[TOKEN.194]}' }

This indeed does not validate against the framework JSON Schema definition as it's neither a CloudFormation intrinsic function, neither a string starting with arn:. The ${Token...} string is a CDK placeholder, that will be resolved at later stage.

One of those stage is the variable resolver called on ${construct:...} occurrences in the service file definition. However, the current observation would led to believe variable resolution actually happens after service file validation, which I find really strange. It is also strange that similar issues were not submitted on Lift earlier to emphasize this problem, I'm guessing the arn property from stream event type has a much stronger typing than other places where ${construct:...} variable resolver is usually used.

This might be worth asking around on https://github.com/serverless/serverless side to check if we can have their input on this issue. Would you care opening a linked issue on their side referencing this one ?

In the meantime, I implemented a small PR showcasing this issue in Lift unit tests suite.

[jcranendonk]

Serverless says it's Lift :shrug: Sounds like we're in a catch-22.

[cmcnicholas]

Resurrecting this one, is there anything I can do as an investigation to help support moving this on?

With serverless 4, the default is going to be set to "error" for config issues so lift will fail immediately with the documented approach.