Array config not serialised properly using chatops

Hi,

I created a pack where actions load their default value from the configuration file. It was working fine executing the action with the st2 cli but not when using chatops aliases for the actions. Suddenly the "arrays" of my configuration were not parsed as such.

Here's the config schema:

hosts:
  description: "List of hosts to access"
  type: "array"
  required: true

Here's my action definition:

---
description: Display the config context of this pack
enabled: True
runner_type: "local-shell-cmd"
name: show_config
pack: mypack
parameters:
  cmd:
    type: "string"
    description: "The Command to execute"
    required: true
    default: "echo '{{ config_context.hosts }}'"
  test:
    type: "array"
    description: "Just a test"
    required: true
    default: "{{ config_context.hosts }}"

The alias:

---
name: "show_config"
pack: "mypack"
action_ref: "mypack.show_config"
description: "Display the current configuration of mypack"
formats:
  - "show config mypack"
ack:
  format: "Retrieving that for you!"
result:
  format: |
    {% if execution.status == "succeeded" %}
      Here's the config:
        {{ execution.result.stdout }}
    {% else %}
      {% if execution.result.stderr %}*Stderr:* ```{{ execution.result.stderr }}```{% endif %}
    {% endif %}

And the chatops result:

juanwolf 10:36 AM
! show config mypack

Stanley 10:43 AM
@juanwolf: I'm sorry, Dave. I'm afraid I can't do that.
u'{{ config_context.hosts }}' is not of type u'array'

Failed validating u'type' in schema['properties'][u'test']:
{u'default': u'{{ config_context.hosts }}',
u'description': u'Just a test',
u'required': True,
u'type': u'array'}

On instance[u'test']:
u'{{ config_context.hosts }}'

Am I doing something wrong here?

Reproduce the pack configuration through the st2 CLI and the ChatOps alias, comparing how config_context.hosts reaches the array-typed test parameter. Trace the ChatOps alias execution and schema validation paths; done when the array-valued configuration passes validation and behaves consistently in both invocation paths.