serverless: Deploy Error: IamPolicyLambdaExecution - LogGroup doesn't exist

This is a Bug Report

Description

What went wrong? After updating to v1.1.0, adding cfLogs: true to my config, and deleting my existing CloudWatch log groups as instructed by the CLI, I can no longer deploy my functions.
What did you expect should have happened? Functions should deploy and log groups should be recreated.
What was the config you used?

frameworkVersion: 1.1.0
service: my-service-name

provider:
  name: aws
  cfLogs: true
  runtime: nodejs4.3

  iamRoleStatements:
    - Effect: "Allow"
      Action:
        - "dynamodb:GetRecords"
        - "dynamodb:GetItem"
        - "dynamodb:Query"
        - "dynamodb:Scan"
      Resource:
        - "*"

# ...

What stacktrace or error message from your provider did you see?

An error occurred while provisioning your stack: IamPolicyLambdaExecution
     - Template error: LogGroup /aws/lambda/my-service-name-dev-functionName
     doesn't exist.

Additional Data

Serverless Framework Version you’re using: v1.1.0
Operating System: OSX

About this issue

Original URL
State: closed
Created 8 years ago
Reactions: 25
Comments: 41 (8 by maintainers)

Most upvoted comments

@big-kahuna-burger This is a CloudFormation level bug, confirmed with AWS support (they were able to reproduce it).

The only quick fix besides what you did with provider level role is to rename your functions so no function is a prefix of another function.

+12

shortjared on Feb 1, 2017

Here’s what I’ve distilled it down to: https://github.com/geoffdutton/serverless-loggroup-test

It works if you use the same prefix, but as long as there more to it i.e. someFunction and someFunctionAgain will cause this, but someFunction and someOtherFunction will not cause it.

I’ve also checked that the log group get’s created, and it does.

So weird…

Edit: I also tried with 20 functions, and it’s come down to the prefix issue.

geoffdutton on Jan 30, 2017

@shortjared Can you post the AWS thread so people can complain to AWS instead of complaining here?

dashmug on Feb 20, 2017

Still occurring:

14:49:52.139      OS:                     linux
14:49:52.139      Node Version:           6.10.3
14:49:52.139      Serverless Version:     1.20.0

noetix on Oct 5, 2017

Hi,

I tested just now with the gist provided by @bsamuel-ui and it looks like the issue of similar name in LogGroup in Cloudformation has been fixed.

Thanks.

sharuzzaman on Aug 30, 2017

I found this forum post if you want to bug AWS about it.

bsamuel-ui on May 30, 2017

Have there been any update from AWS about this?

cc @pmuens @eahefnawy

hassankhan on May 26, 2017

Renaming helped. Renamed like this:

v1UsersGet => f06v1UsersGet
v1UsersPost => f07v1UsersPost

Hope it does not cause any blockers in the future.

pgasiorowski on Feb 23, 2017

I’ve verified the claims above. My workaround for this is to change the name.

So, instead of:

someFunction:
  handler: handler.someFunction

someFunctionCallback:
  handler: handler.someFunctionCallback

I just rename one of the functions:

someFunction:
  handler: handler.someFunction

2SomeFunctionCallback:
  handler: handler.someFunctionCallback

faizhasim on Nov 6, 2016

May have narrowed down the issue to a problem with function naming conventions. After commenting out the function definitions in my serverless.yml, I noticed that I could successfully deploy all but 2 of the 9 functions in this service.

The only thing that stands out about these two functions is that their names are a subset of two other functions in the service. E.g.:

functions:

  # This function deploys fine
  haListingContentIndex:
    # ...

  # This function fails
  haListingContent:
    # ...

If I remove the stage (delete the CF stack), and comment out either one of these functions, the deploy will be successful.

adambiggs on Nov 3, 2016