-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SSM: StringParameter.valueFromLookup should return undefined if SSM parameter not available #22064
Comments
Thank you for the ticket, I've labeled this as both a bug and feature-request since it seems to be a bit of both. One approach you could take would be to use a custom resource as mentioned here: #7259 (comment) to handle fallback values. |
We just got hit by this as well, it certainly seems like a bug. |
@astef Just to clarify, when you say "it crashes", do you mean that the CLI prints an error message like this:
and returns exit code 1? If that's the case, the template is still generated. To know whether the parameter exists at runtime, check whether the value starts with "dummy-value-for-". |
This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled. |
@otaviomacedo Thanks - but that doesn't solve the |
This It prevents conditionally creating resources by testing whether an ssm value exists. Take a look as the aws-cdk-lib ssm documentation #lookup-existing-parameters.
This is no longer true. In actuality,
Just looking up the value with
|
Wrong, this remains true. In your case, I think the issue is that SSM is not being able to fetch your stack scope properly. From the method description:
|
Ah, thank you for the correction / clarification, @T-Guerrero. |
Just faced this issue too, exit code 1. Template is generated with dummy value however exit code 1 hurts e.g. automated pipeline. |
One issue can be if you aren't passing the stack props to the super constructor. This will cause the stack to not detect the env even though it is specified in the stack props. Here is a C# example:
|
…arameter (#31415) Updates StringParameter.valueFromLookup with an optional "defaultValue" When specified this value will be used: - in place of the standard dummyValue - to signal that an Error should not be raised during synthesis if the parameter is not found in the account. Test are updated to prove that this works ### Issue # (if applicable) Resolves #7051 There are some closed issues which also benefit from this change: - #22064 - #7259 ### Reason for this change We have a library which has a fixed set of SSM parameters on which it depends. The values from those parameters are made available as attributes of a custom Stack. We have many users in many different AWS accounts, and not all of the parameters are guaranteed to exist. This is okay. In general, teams would simply not use those values and be happy with that outcome. Unfortunately, CDK crashes when you look up an SSM parameter that does not exist in the account. This is unacceptable. ### Description of changes To address the issue described above, I implemented an optional parameter on the `valueFromLookup` method: `defaultValue`. The idea is that if this value is specified, and we fail to look up a parameter in the account, we will return this value and suppress the Error that is currently raised when a parameter is not found. To implement that functionality, I added a field to the `GetContextValueOptions` interface which is used to flag that we're not going to raise the error. Then, in `valueFromLookup`, I set that flag to `true` if the `dummyValue` is specified. `valueFromLookup` then calls `ContextProvider.getValue` passing along those values. `ContextProvider.getValue` is modified so that when it calls `stack.reportMissingContextKey` it passes a modified set of `props` which include the `defaultValue` and the `ignoreErrorOnMissingContext` flag. These finally land in the `aws-cdk` context provider for `ssm-parameter`. That code has been updated so that if the value is not found in SSM, and we're told to suppress the error, then we'll simply return the `defaultValue` that was passed in. ### Description of how you validated changes I added a unit tests which covers when the default value is set. I also updated the original unit test as the `props` now contain some additional field. I added an integration test which calls `valueFromLookup` with a `defaultValue` set and then confirms that no exception is raised and that `valueFromLookup` returned the `defaultValue` **NOTE** I considered that the changes made _might_ need to be a part of the `cloud-assembly-schema` but chose to work around that for now. I'm open to incorporating them there if that's a more correct path. **NOTE 2** I'm unsure about how to update API documentation for this change. This does alter the public API for `valueFromLookup` and the function doesn't appear to have a proper `TSDoc` header on it. Please let me know if there's a proper way for me to update the documentation. ### Checklist - [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md) ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Describe the feature
When using
ssm.StringParameter.valueFromLookup
, it crashes (not sure, but error is not catchable), when the parameter doesn't exist. It makes it unusable for scenarios with a fallback parameter.Use Case
For a short-lived infrastructure it's both important to be configurable (create a parameter & deploy), and have a nice fallback value (just deploy). SSM parameter is a perfect solution, since it can be resolved at synth time. It's very unfortunate, that currently it's impossible not to crash, when the value doesn't exist.
Proposed Solution
Return undefined, instead of crashing, or expose a better API, with multiple fallback parameter names to check.
Other Information
This issue was also discussed here: #7259
Acknowledgements
CDK version used
2
Environment details (OS name and version, etc.)
Any
The text was updated successfully, but these errors were encountered: