-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CloudFormation did not receive a response from your Custom Resource #192
Comments
Can't explain it, it is really weird that some custom resources would time-out while others don't. All of them have been coded similarly and handle uncaught exceptions. They don't need permission to callback to the CloudFormation signed URL, so that can't be it either. You'll have to look in the CloudWatch logs of the concerned Lambda functions and see what that says. Log group names you'll need to look in should be similar to:
|
Tried looking in Cloudwatch, but since it doesn't initiate the creation of those custom resources, there's nothing in Cloudwatch to point us in a direction. This is literally the only thing holding up the full deployment at this stage from what I can see. |
Can you paste a screenshot here, of the CloudFormation events tab that shows the errors? You could try navigating to these lambda functions and just running them with a test payload (doesn't have to be meaningful) just to see what you get yourself if you try to invoke them. There might be a very fundamental error, that prevents CloudFormation from running them, you should see that yourself then too.
|
Cheers mate! I see e.g. "StaticSiteHandler" is blue and a valid link? That's what I'd be after, that takes you to the Lambda that implements the "StaticSite". If you run that Lambda manually, with a dummy payload, what happens? It should fail because that dummy payload is invalid (expected) but not because of some other error (like import errors, or code parse errors). Note, that Lambda function should write logs to CloudWatch (that you can navigate to from within the Lambda function, in the monitoring tab). The Lambda function might be cleaned up by CloudFormation when the stack fails to deploy (unless you use |
Ok, I'll try and get you that data today after all my morning meetings :) Yeah, I used the --disable-rollback function since we're testing in our nonprod environment just for that reason. I've just not been able to find anything in cloudwatch related to why it's not initiating the creation of those 3 custom resources. Hope to have more info for you soon! |
So, one this I see is this (just trying to click through to Cloudwatch from StaticSiteHandler): Log group does not exist. The specific log group: /aws/lambda/uopx-nonprod-myresource-StaticSiteHander-xxxxxxxxxx does not exist in this account or region. That's not what I should see correct? |
Just for giggles, I ran a test using the default test data (no passing in anything really) and this is the error I see: |
Well there's the culprit. Not sure I understand the error completely. Was compiling the |
Good question. Let me rerun the build and see what happens. It's been a minute. Stand by! |
So, no, it's not compiling looks like (using npm run build):
npx: installed 1 in 1.389s
To get access to the TypeScript compiler, tsc, from the command line either:
npm ERR! A complete log of this run can be found in: npm ERR! A complete log of this run can be found in: |
Looks like you need to still run |
Ok, I did npm install and then npm run build, and that all worked, so cheers on that! Should I do another sam deploy now and see if we get different results? Sorry for all the stupid questions, I'm just still very new with all this. |
Indeed. Basically follow these instructions closely: https://github.com/aws-samples/cloudfront-authorization-at-edge#deployment |
Yeah, I thought I did, but apparently not, so I feel a little foolish possibly wasting your time. I appreciate your patience! I'm going to clean up my current deploy (since it'll want to delete those 3 failed resources anyway) but that requires another team since they handicap our ability to delete resources (frustrating). I'll get back to you with updated results later today. |
Sure thing, and no worries -- debugging Custom Resources can be a pain unfortunately. |
Hi Omar! Well, it MOSTLY worked this time!! All the custom resources created, the only thing that failed was the actual S3 bucket creation with this error: CREATE_FAILED AWS::S3::Bucket S3Bucket Value of property Tags must be of type List That's something we should be able to work through I think. I just have to figure out where it's failing on that. We added some Tags: properties within the S3 bucket resource because it wasn't creating them and getting purged by our sentinel policies. Thanks so much. I'll let you know when we're 100% successful, but we're almost there :) |
We finally got a full deploy done. Looks like everything is good now (we fixed the cloudfront log ACL issue on our end and added in Tags in the S3 bucket resource). Thank again for your help!! |
Great! Our perseverance payed off in the end |
Hi, we seem to be stuck at this last piece of trying to deploy. The cognito fixes you implemented worked great and we no longer see that issue, but we have been having problems from the start with these custom resources: NonceSigningSecret, HttpHeadersHandlerCodeUpdate, and StaticSite. On all the other resources, we do see a status of Resource creation initiated and the resource itself created, but for those three, we never get to a point where it initiates the resource creation. The actual error we get for those three is: "CloudFormation did not receive a response from your Custom Resource. Please check your logs for requestId [85c5c344-6284-404c-9a0a-6b4f772d6c05]. If you are using the Python cfn-response module, you may need to update your Lambda function code so that CloudFormation can attach the updated version."
We've looked through this and cannot determine why we consistently get this error. The code doesn't appear to be using Python, instead using TypeScript so maybe it's a generic error? Any help you can provide to get us over this last bit of issue is greatly appreciated. We've tried Googling the error, but cannot find anything useful.
The text was updated successfully, but these errors were encountered: