3

This is now resolved, but I'd like to leave it in case it helps someone else. The issue was that I misinterpreted the error. I interpreted "property Responses not defined for resource of type Api" to mean that I hadn't defined any, when it actually meant that an Api resource doesn't have a property called Responses. I don't know why it worked earlier, but once I removed the Responses entry, the deployment succeeded.

3 weeks ago I created a CloudFormation stack for the creation of an API gateway with lambda functions.

I used the dotnet lambda.EmptyServerless project type (on a Mac running Visual Studio Community Edition).

I successfully deployed the app via the dotnet cli many times using 

dotnet lambda deploy-serverless

But as of yesterday, the deployment fails with the error

Failed to create CloudFormation change set: Transform AWS::Serverless-2016-10-31 failed with: Invalid Serverless Application Specification document. Number of errors found: 1. Resource with id [PostRegistrationPutResource] is invalid. property Responses not defined for resource of type Api

This is the exact same template I used before; the method is not new and I haven't changed its Resource entry.

Here is the relevant entry (formatting is correct but changes when I past it here):

  PostRegistration:
Type: 'AWS::Serverless::Function'
Properties:
  Handler: 'lambda::lambda.Functions::GetWorkshops'
  Runtime: dotnetcore2.0
  CodeUri: ''
  MemorySize: 256
  Timeout: 30
  Role: null
  Policies:
    - AWSLambdaBasicExecutionRole
  Events:
    PutResource:
      Type: Api
      Properties:
        Path: /registration
        Method: POST
        Responses:
          method.response.header.Access-Control-Allow-Origin: '''*'''

Here are some things I feel may be relevant about my environment:

  1. I updated to the latest High Sierra version last week.
  2. Because of that update, ssh handshakes were broken for access to RDS databases.
  3. In order to get access to my databases back, I downloaded both the latest dotnet core version and a version of SQL Operations that included a fix for the ssh issue.

Another symptom of strangeness was that when I tested this lambda function directly on the Lambda Management site, it failed to read the body of the post and therefore the lambda failed. This is what caused me to try to rebuild the stack in the first place - I was not seeing data posted that should have been.

When I ran my unit test from with VS Community for the post operation, it failed with the same ssh issue that I saw with SQL Ops yesterday.

As a last resort, I deleted the whole stack (it's still in dev) and tried deploying again, with the same error result.

I don't know what else to try, and I cannot find any other reference to this type of problem.

Clues, anyone?

glitchbane
  • 327
  • 5
  • 11

1 Answers1

0

I was facing same issue, but solved with following

CodeUri:
    Bucket: !Ref LambdaBucketName
    Key: abc.zip

CodeUri must have Bucket and key parameters and values.

Dipika Joshi
  • 639
  • 1
  • 5
  • 13