Strings from $input.params are not of 'str' type so cannot use methods

[bmcgavin]

I was trying to find out why 'contains' function calls in my API Gateway templates were not working.

I added a print(current_object.__class__) call to https://github.com/localstack/airspeed/blob/master/airspeed/operators.py#L622 (which is L615 in my local copy, localstack 2.3.0 pulling in airspeed-ext>=0.6.1).

Given this template:

        #set($origin = $input.params("origin"))
        #if($origin.contains("test"))
          yes!
        #end

I get nothing, and the print shows

<class 'localstack.utils.aws.templating.VtlTemplate.render_vtl.<locals>.ExtendedString'>

By altering the template slightly to interpolate the string:

        #set($raworigin = $input.params("origin"))
        #set($origin = "${raworigin}")
        #if($origin.contains("test"))
          yes!
        #end

Then I get the expected output, and the debug print shows

<class 'str'>

Which means airspeed can use the __additional_methods__ dict as expected.

Is this a bug or are users expected to interpolate parameters in this way?

[calvernaz]

Hi @bmcgavin, thanks for reporting this. I'll take a look, this looks like a bug on our side.

[calvernaz]

Hi @bmcgavin it sounds to me you might be using an older version.

v0.6.4: add support for string.indexOf, string.substring and array.isEmpty
v0.6.3: array notation for dicts using string literals and merge upstream patches
v0.6.2: add support to contains and toString functions

Can you try with a newer version of localstack? Thanks

[bmcgavin]

Apologies for the delay - this is still present in localstack 2.3.2, which pulls in airspeed 0.6.3. The debug print still shows the same non-string type.

Thanks for taking a look into this. While I could test on 0.6.4, I can't see anything in the commit that would affect how the type is being decided, only methods that are able to be called once the variable is seen as a str.