Chatops keyword parameter passing broken

[vincent-legoll]

SUMMARY

I upgraded stackstorm to the new 3.0.1 and our way of calling slack chatops with named parameter is not working any more.

!newbuild name=truc gittag=c4deadbeefd03266f1ba7042b14b31a release=unstable github_packaging_branch=10.32

output:

I'm sorry, Dave. I'm afraid I can't do that.
Command "newbuild name=truc gittag=c4deadbeefd03266f1ba7042b14b31a release=unstable github_packaging_branch=10.32" doesn't match format string "newbuild {{name=truc}} {{gittag}} {{release}} {{github_packaging_branch}}"

whereas the following is OK:

!newbuild truc c4deadbeefd03266f1ba7042b14b31a unstable "10.32"

This was working fine before.

ISSUE TYPE

• Bug Report

STACKSTORM VERSION

st2 3.0.1, on Python 2.7.5

OS / ENVIRONMENT / INSTALL METHOD

Bare-metal CentOS 7 + EPEL (up to date)

STEPS TO REPRODUCE

!say phrase=toto in color=red

EXPECTED RESULTS

I have it covered. Your execution ID is 5cfa92a935e378177eae1d39 (details available at https://stackstorm.novalocal/#/history/5cfa92a935e378177eae1d39/general)
@Vincent:
Noop
Action core.noop completed.
status : succeeded
execution: 5cfa92a935e378177eae1d39

web_url: https://stackstorm.novalocal/#/history/5cfa92a935e378177eae1d39/general

Took 0.459185\u03BCs to complete.

result :
--------
failed : False
 Show more

ACTUAL RESULTS

@You: I'm sorry, Dave. I'm afraid I can't do that.
Command "say phrase=toto in color=red" doesn't match format string "say {{phrase}} in {{color}}"

[arm4b]

Can you provide sample action alias? This will make it easier for someone to reproduce in future.

Which st2chatops package version you used, that worked well before with mentioned construct?

[vincent-legoll]

Doesn't the say example help to reproduce it ? I thinks this is not a local pack problem but a more generic one. I can remove the misleading newbuild alias-related text from the summary if that is unhelpful.

I don't remember the exact versions we had before, I'll try to dig it out of our pkg installation log files...

Update, here are the latest upgrades made to st2chatops package:

Mar 22 17:38:39 Updated: st2chatops-2.10.4-1.x86_64
May 27 14:42:16 Updated: st2chatops-3.0.0-1.x86_64
Jun 06 16:48:53 Updated: st2chatops-3.0.1-1.x86_64

2.10.4 was working OK
It looks like 3.0.0 was also OK
3.0.1 definitely is not OK

But the 3.0.1 update came with a bunch of other package updates:

Jun 06 16:48:42 Updated: st2mistral-3.0.1-1.x86_64
Jun 06 16:48:45 Updated: 2:nodejs-10.16.0-1nodesource.x86_64
Jun 06 16:48:53 Updated: st2chatops-3.0.1-1.x86_64
Jun 06 16:49:03 Updated: st2-3.0.1-4.x86_64
Jun 06 16:49:03 Updated: st2web-3.0.1-1.x86_64
Jun 06 16:49:04 Updated: 1:libuv-1.29.1-1.el7.x86_64

libuv was at the following version before jumping to 1.29.1

Apr 09 11:08:19 Updated: 1:libuv-1.27.0-1.el7.x86_64

And nodejs was at :

Mar 08 15:24:58 Updated: 2:nodejs-10.15.3-1nodesource.x86_64

[vincent-legoll]

What is strange is that some other aliases don't have the problem and work with keyword arguments passed through slack. Maybe some leftovers/buglet from a pack alias regex matching change on our side...

I actually have changed the newbuild alias definition to remove some previously set default values, to force people giving them explicit values.

[arm4b]

Just to be sure, are you saying you have forked st2 or st2chatops core with some custom regex rules?
Or do you mean matching regex in action alias itself (action alias format https://docs.stackstorm.com/chatops/aliases.html#regular-expressions) ?

[vincent-legoll]

Nope, I don't have forked anything, the packages have always been pristine from upstream repository, and are now the at versions cited above. When I said "change", it's in my pack code, in the matching regex in action alias format string as you rightly supposed.

What is strange is some of our own aliases continue to work properly with keyword arguments (not sure if it's the right word, I use the python denomination), whereas others don't.

What is also strange is that the upstream alias say is showing the problem, whereas I have not changed it, apart from the eventual change coming from official upstream version upgrade.

[stale]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically marking is as stale. If this issue is not relevant or applicable anymore (problem has been fixed in a new version or similar), please close the issue or let us know so we can close it. On the contrary, if the issue is still relevant, there is nothing you need to do, but if you have any additional details or context which would help us when working on this issue, please include it as a comment to this issue.