pass without exception if jinja parameter isn't found

[guzzijones]

If a jinja parameter doesn't exist as an input parameter then do not throw an exception and leave the value as a string parameter.
We have some input paramters like:

{ "test": "{{some_text_here}}"}

These cause stackstorm to attempt to resolve some_text_here as a variable since it has matching {{ and }}.

This pr would allow those through as normal strings if they cannot be resolved.

[CLAassistant]

All committers have signed the CLA.

[cognifloyd]

Maybe we could:

• collect a list of nodes (vars) that aren't valid as template vars
• if ANY of the vars DO exist, throw an error for the missing nodes.
• if NONE of the vars exist, then assume it is a string and ignore.

Otherwise, I'm concerned this could hide misspellings.

[guzzijones]

I don't understand:

collect a list of nodes (vars) that aren't valid as template vars

[guzzijones]

Most, if not all, my actions already have a jinja template parameter for {{config_context.var}}. So I don't think check if ALL are parameters would work in my case.

We have a lot of log files with {{...}} in the json as a string. These are unable to be processed by Stackstorm currently.
I actually don't understand the use case for putting {{...}} templating parameter evaluation inside stackstorm except for the case of config context or secrets from the KV store.

One can always just utilize a parameter in their python script.

[nzlosh]

I'd rather see a more deterministic method to processing (or not) template strings. For example, adding a new input data type raw_string, which will not attempt to process the input variable and treat it at as raw string until it is handed off to the workflow/action. string would remain unchanged and process strings against template detection.