Brave New Variable Resolver World

Hello All,

I’ve found myself in a bit of chicken and egg situation. I’ve just embarked on upgrading to serverless 2.35.0 (from 1.67.3).

I noticed a depreciation warning:

Serverless: Deprecation warning: Variables resolver reports following resolution errors:
  - Variable syntax error at "resources.5.Resources.RoleCognitoAuthenticatedUser.Properties.Policies.0.PolicyDocument.Statement.2.Resource.Fn::Join.1.1": Missing variable closing bracket in /private/${

  From a next major this will be communicated with a thrown error.
  Set "variablesResolutionMode: 20210326" in your service config, to adapt to new behavior now
  More Info:

Fair enough I thought, the line it is warning about is using some trickery to to split the trailing } on to a new line to avoid sls from interpreting the variable, the intented target being AWS CF.

    - ""
      - Fn::GetAtt: [ Bucket, Arn ]
        - "/private/${"
        - "}/*"

To resolve this I discoverd variableSyntax provider setting. I set it up the regex so that sls variable syntax is now ${{...}} and collapsed the - "}/* into the preceeding line. I then enabled variablesResolutionMode: 20210326 only to discover that as of release 2.31.0 these are mutualy exclusive (from change log: Variables: Disallow provider.variableSyntax with new resolve).

What is the approach to disambiguate between sls and AWS CF variables when running under the new variable reslover? Documentation found at is of not much help.

For now I have resorted to removing the opt in to the new variable resolver and continue with variableSyntax approach.

@rdamico this is a sligthly tricky case. As per current spec used format matches Serverless variables.

Easy fix for now is that you can use Fn::Join to split "/private/${" string in a way that Serverless variables resolution does not trigger. I assume following would work:

    - ""
    - - "/private/${"
      - ":sub"

Stil, this experience will be improved:

  1. New variables resolver support escape characters, so e.g. "/private/\${" won’t be picked. However, current shortcoming is that those escape characters are not cleared, hence at this point I cannot recommend this as solution. Track Variables: Clear escapes from escaped variables · Issue #9288 · serverless/serverless · GitHub for that
  2. With next major (v3) we will narrow allowed format for scope name, and just that will solve this issue. Track Variables: Make scope name format more strict · Issue #9289 · serverless/serverless · GitHub for progress on that
1 Like

Thank for the information! Will defintely track those issues.