Fix: Cfn: non-string parameter values

[simonrw]

Motivation

A customer had an issue when they used a non-string Parameter value, e.g.:

Parameters:
  MyValue:
    Type: Number
    Default: 5

When this parameter is used within a Fn::Sub expression:

  Value:
    Fn::Sub: "my value is ${MyValue}"

it causes an error: Could not resolve {'Ref': 'MyValue'} to terminal value type. This is because we raise an error if any Ref type that we resolve does not eventually resolve to a string. This is limited however, as the parameter value is a number, but really the error should be related to if the ref cannot be resolved beyond a structured type, e.g. dict, list or tuple.

[!WARNING]
The true fix probably involves casting all parameters to strings, but using the Type for something... Not quite sure yet at this stage. This PR however applies a bandage over the problem so at least this error does not continue to happen. In the future, we should look into proper parameter/ref handling.

Changes

• Only raise the existing exception if we resolve a ref to a structured type.
• Add minimal test that asserts the value is propagaed through the parameter and Fn::Sub invocation.

[github-actions[bot]]

LocalStack Community integration with Pro

    2 files  ±0      2 suites  ±0   1h 46m 6s ⏱️ + 3m 1s 3 510 tests +1  3 097 ✅ +1  413 💤 ±0  0 ❌ ±0  3 512 runs  +1  3 097 ✅ +1  415 💤 ±0  0 ❌ ±0 

Results for commit c56aff20. ± Comparison against base commit 62a302ca.

:recycle: This comment has been updated with latest results.