this obviously applies to empty vars too. we use SSM to populate envars and sometimes want that var to be empty +1

Hey all, we just released v1.29.2 patch that includes a fix for this. Thanks to everyone for reporting, and special thanks to @horike37 for the fix! 😊

@serverless/framework-maintainers I have fixed this on #5166. Please review it.

I’m getting this with v1.29.2. It only happens on package or deploy, but works great when debugging with offline.

serverless.yml:

environment: ${file(config/env.yml):${self:provider.stage,'local'}} … arn: ${self:provider.environment.events.crm.my_event}

env.yml:

default_env: &default_env
   events: ${file(config/event-names-${self:provider.stage}.yml):events} # this line is the problem. replacing with a string solves the issue. replacing with a nested object throws the same error.

local:
  <<: *default_env
  aws:
    sns:
      endpoint: "http://127.0.0.1:4002"
      region: "us-east-1"

dev:
  <<: *default_env
  
prod:
  <<: *default_env

event-names-local.yml:

events:
  crm:
    my_event: "arn:aws:sns:us-east-1:8xxxxxxxxx...."

Error message when trying to deploy:

Environment variable events must contain string

This bug was unintentionally introduced by #4890. My possible solution to the problem is here

• Remove only contain string check when sls deploy. This cause the breaking.
• Add single-quotation to env value itself just before deploying to avoid the Lambda API error if it contain only number when sls deploy function

We should cut a patch release as soon as possible.

cc: @serverless/framework-maintainers

Same here… fourthed?

@timgivois I 100% agree the breaking change is in Serverless, and I would even go so far as to say it shouldn’t even be a warning and should quietly coerce all primitive types to a string.

@jamesdixon that doesn’t sound right to me. These values should be read from process.env which always returns a string from what I can tell. Thus I would expect those libraries to coerce the string values into the required type.

However, I still think having a breaking change in 1.28 is not ideal!

I’m having this issue too. I had to downgrade:

npm i -g serverless@1.27.3

Add single-quotation to env value itself just before deploying to avoid the Lambda API error if it contain only number when sls deploy function

Don’t forget null, true, false, and any other non-number & non-string field types.

+1 (also thumbed up 👍 the initial comment). We had multiple pipelines begin failing late last week, and traced it back to this breaking update. May make us rethink our pinning serverless versus vs. leading latest, but hoping 1.28.1 is coming soon. Also wonder regarding any future alignment to semver versioning for the package? We’d love to understand when breaking changes are coming (2.x) to make a decision, and let us pin to 1.x for all backward-compat feature enhancements, security patches, etc.

+1, Thanks!

Thirded.

This also happens during sls package not just sls deploy.

@horike37 Agree. We should put that into 1.28.1. I will create a patch branch and cherry pick as soon as a solution is ready.

Add single-quotation to env value itself just before deploying to avoid the Lambda API error if it contain only number when sls deploy function

Is this enough, or do we have to cover cases where an env var is set to an object too?