Open kalevalp opened 4 years ago
@kalevalp you don't need pseudo-params in this case, you can reference the checkairtable
function like this:
CheckAirtable:
Type: Task
Resource: !GetAtt checkairtable.Arn
End: true
normally you have to use the logical ID for the function (which in this case would have been CheckairtableLambdaFunction
, but we made a change in this plugin to let you use the local function names in the definition
section.
Sure, but it still seems like a bug. At least in that the error is hard to figure out from the error message. Also, considering that this use case of pseudo parameters appears in the serverless-pseudo-parameters, I expect more people to encounter it.
I opened this issue after investigating the bug in this SO question.
Also, apparently there is already an open issue for serverless-pseudo-parameters on the same bug.
The problem is with the asl-validator which is not aware of the #{}
syntax. And arguably it has no reason to, since it's a library for validating SFN state machine definitions and is not specific to the Serverless framework.
Also, as a side, we (as in, this serverless-step-functions
plugin) actually translate those #{}
pseudo parameters ourselves so the serverless-pseudo-parameters
plugin doesn't even kick in. This is because there's an incompatibility with the serverless-pseudo-parameters
plugin (see #252) in the way it tries to insert a Fn::Sub
but we also need to use Fn::Sub
ourselves too.
https://github.com/serverless-operations/serverless-step-functions/pull/264 fixed fixed the incompatibility but still, validation is done before replacement, which makes it fail. Moving the replacement before the validation should fix this.
This is a Bug Report
Description
Validation fails when a resource in the state machine uses
serverless-pseudo-parameters
pseudo parameters.This is the deployment:
This is the error message:
Env info:
Plugin versions are: