Even after writing software for 30 years, it still amazes me how much time I waste on small little issues that crop up out of the blue. However, what may be even more fascinating is that after I discover what the issue is, it always turns out to be something that I did wrong. Just once I wish it was a mistake that someone else had made.

Case in point…I am currently working on an Alexa Skill that I initially created locally with the ASK-CLI.  I had not done any work on the Skill Interface code, but I had spent a fair bit of time locally developing the Skill Service code, which was a Lambda function.

After a while I had the Lambda code where I wanted it to be, so, I decide to deploy this Lambda code that I wrote with ‘ask deploy’

Here is what I got…

Well that’s an interesting error….

ValidationException: 1 validation error detected: Value ‘ask-custom-Ui.Voice-default’ at ‘functionName’ failed to satisfy constraint: Member must satisfy regular expression pattern: (arn:(aws[a-zA-Z-]*)?:lambda:)?([a-z]{2}((-gov)|(-iso(b?)))?-[a-z]+-\d{1}:)?(\d{12}:)?(function:)?([a-zA-Z0-9-_]+)(:(\$LATEST|[a-zA-Z0-9-_]+))?

Seems like an issue with deploying the Lambda Code…something was wrong in my code perhaps….but what…everything ran fine locally !!!!

After quite a bit of googling the above error, I couldn’t come up with a solution, so I went back to basics.

I figured I would create a new Skill based on the basic template code, and deploy without making any changes.

So I made that new Skill and here is what I got when I went to deploy….

Same error….

ValidationException: 1 validation error detected: Value ‘ask-custom-Ui.Voice-default’ at ‘functionName’ failed to satisfy constraint: Member must satisfy regular expression pattern: (arn:(aws[a-zA-Z-]*)?:lambda:)?([a-z]{2}((-gov)|(-iso(b?)))?-[a-z]+-\d{1}:)?(\d{12}:)?(function:)?([a-zA-Z0-9-_]+)(:(\$LATEST|[a-zA-Z0-9-_]+))?

After more time searching online, I came across something that led me to the solution.

The first Skill I created was called UI.Voice and the second Skill was called UI.Voice2, so the paths to the code files were



Now I guess the ASK-CLI, or maybe Lambda itself,  doesn’t like to deal with periods in the name of the Alexa Skill, or in the path to the code,  and that rather cryptic error is the result.

Creating and Deploying a third Skill who’s name did not contain a period resulted in this…

Problem Solved…or is it !!!

Further testing uncovered that you cannot use an underscore character in the name of your Skill either. (although you get a different error when you try to deploy – Skill not found)

So the end result is, don’t put periods or underscore characters in the name of your Alexa Skill if you are going to create & deploy with the ASK-CLI.

I don’t know why that is…but at least I now know not to do it.

Hopefully this helps someone else out.

Thanks for reading.

This Post Has 2 Comments

  1. I just smashed my face into this same problem! I have already wasted hours trying to figure out what is going on and reading your thought-journey was super helpful.
    I’m still not sure what the right path forward is. I try to keep my VS projects named the same as their default namespace, which means periods in the file path. AWS seems to prefer hyphens for everything, but C# doesn’t allow hyphens in namespace/class names.
    Like you, I have been doing this a long time, and all of these naming restrictions feels a lot like the ridiculous state of affairs circa 1987

    1. Glad the post helped you out…your comment about 1987 is accurate

Leave a Reply

Close Menu