Overwriting variable resolution require string fallbacks to be fully resolvable

Bug Report

Description

1. What did you do? In my serverless.yaml I declare a variable with this syntax: ${env:SomeUrl, "${cf:my-stack.ServiceEndpoint}/api"}. My intent is to use the cloudformation resolution (which only gives part of url) in most cases. But in some cases I want to override the URL by a sysenv variable. For example when there is no “my-stack” deployed. But if I set env variable SomeUrl and my-stack is not deployed deployed, it fails 😦

2. What happened?

ServerlessError: Stack with id my-stack does not exist

3. What should’ve happened? The resolver should succeed by just successfully resolve env:SomeUrl. Because the second part is only some kind of fallback it is of no interest if the first part is resolvable.

4. What’s the content of your serverless.yml file?

custom:
  - someurl: ${env:SomeUrl, "${cf:my-stack.ServiceEndpoint}/api"}

5. What’s the output you get when you use the SLS_DEBUG=* environment variable (e.g. SLS_DEBUG=* serverless deploy) I call SLS_DEBUG=* SomeUrl=http://localhost/foo sls package

The output is

[...]
Serverless: [AWS cloudformation 400 0.267s 0 retries] describeStacks({ StackName: 'my-stack' })

  Serverless Error ---------------------------------------

  ServerlessError: Stack with id my-stack does not exist
      at C:\Users\xyz\AppData\Roaming\npm\node_modules\serverless\lib\plugins\aws\provider\awsProvider.js:329:27
      at processTicksAndRejections (internal/process/task_queues.js:97:5)

  Get Support --------------------------------------------
     Docs:          docs.serverless.com
     Bugs:          github.com/serverless/serverless/issues
     Issues:        forum.serverless.com

  Your Environment Information ---------------------------
     Operating System:          win32
     Node Version:              12.16.1
     Framework Version:         1.65.0
     Plugin Version:            3.4.1
     SDK Version:               2.3.0
     Components Version:        2.22.3

[medikoo]

@sschulze I agree, ideally fallback should be resolved only when we fallback to it. It might be an issue in design of variable resolver. We’re open for PR that improves that.

I’m adding @erikerikson to the discussion, as he has very good understanding of variable resolution mechanism in the Framework, and may provide a valuable insight.

[medikoo]

Closing as it’s works as proposed with new variables resolver, which was shipped recently