I'm currently using lambda function which is invoked using Aws Lex. It was working normally and I didn't modify any of its configuration and out of nowhere it stopped working and I keep getting this error.
/opt/sls-sdk-node/exec-wrapper.sh: does not exist
Can anyone please explain what is an exec-wrapper.sh and how is it possible for it to suddenly disappear? And how can I solve this problem?
This looks to be an error stemming from the Serverless framework rather than an issue with Lex itself. Did you perhaps upgrade any of the SLS dependencies?
It turned out that after removing the serverless framework, there were some configurations (exec-wrapper.sh) that were not removed and needed to be removed manually from lambda using the aws console
Related
Hi guys I’m so sorry if this sounds stupid but I’m still getting familiar with aws, so I don’t know how everything works yet. The thing is I created a react app with amplify and a graphql through amplify Cli and then I created a lambda function to be triggered every time something is added to the table/collection and I would like to develop locally, because right now every time I change the lambda function I have to re deploy it. Can you guys help me? I’m sorry if it doesn’t make sense
You should look into mocking and testing, for example: https://aws.amazon.com/blogs/aws/new-local-mocking-and-testing-with-the-amplify-cli/
You can also get DynamoDB Local as well as run Lambda locally with SAM.
Really stumped right now. I want to use Amplify for a Cloud assignment and have done amplify init in VS Code terminal to create the app. Unfortunately, I've been receiving this error when I try to enable Amplify Studio via the AWS webpage.
I thought my roles and permissions might need to be adjusted but I have AdministratorAccess-Amplify on the users I need. I also couldn't delete any of my test applications due to a similar error, but I managed to delete them via the CLI with no issues.
So my question is, is there any way to enable Amplify Studio via the CLI, or has anyone run into this issue before and been able to fix it?
Thanks in advance.
:)
I created a lambda using the web gui, using Go 1.x. Now I want to edit the code but I don't know how. I downloaded the vscode extension but it only displays the lambda, doesn't give me any options for editing.
What am I doing wrong? How can I edit the code, and ideally run it locally and debug it?
All the tutorials cover how to create a function locally and then deploy it, but for another use case, I need to do it the other way around - there's already a deployed lambda and I need to edit it and write tests for it.
I have aws-cli, sam and docker functional.
From Working with AWS Lambda Functions - AWS Toolkit for VS Code:
The AWS Toolkit for Visual Studio Code provides support for AWS Lambda functions. Using the Toolkit for VS Code, you can author code for Lambda functions that are part of serverless applications. In addition, you can invoke Lambda functions either locally or on AWS.
So, looks like you can only edit Lambda components that are part of a SAM app.
The documentation on AWS-CDK has examples of setting it up as a standalone application with support in multiple languages.
I have the following questions regarding the same:
Is it possible to use it within a separate app (written in .NET Core or Angular) like a library?
By above I mean being able to instantiate the construct classes within my app's services and create stacks in my AWS account.
If yes, how does it affect the deployment process? Will invoking the synth() function, generate the cloud-formation templates as expected?
Apologies if my question is vague. I am just getting started with this and am willing to provide necessary details if needed.
I appreciate any help in this regard. Thank you.
I've tried using cdk as a library, but had a few issues and started calling it from another app by using a cli call.
I was using typescript and basically what I did was to call the synth method on the app construct:
import * as cdk from '#aws-cdk/core';
const app = new cdk.App();
... // do something
const cf = app.synth(); // here you get the cloud assembly
cf.something() // you can manipulate the results here
A few issues I found was to get errors during synth as they were not proper bubbled up.
I couldn't find a way to deal with the assets either...
In summary, I didn't explore it much further than that, but I think cdk might need more development to be able to use all its features when importing as a library.
My Serverless image handler was working fine till now and now i'm getting the following error.
start_thumbor error: pycurl: libcurl link-time ssl backend (openssl) is different from compile-time ssl backend (nss)
This looks like a problem with the version of pycurl.
Please help me resolve it.
Tried changing the pythong version to 3.6 in ServerlessImageHandler lambda function configuration.
I found a discussion about that issue on https://forums.aws.amazon.com/thread.jspa?messageID=909444, which sent me to https://github.com/awslabs/serverless-image-handler/issues/127#issuecomment-514757029.
Github user timkelty has the solution:
go to my CloudFormation Stack
click Update
"replace template"
paste in https://cf-templates-nestrom.s3-eu-west-1.amazonaws.com/serverless-image-handler/1.0/serverless-image-handler.template
so far has worked for me in us-east-1 and us-west-1
AWS has released a new version of Serverless Image Handler this is why everybody suffers now because Thumbor functionalities fail in the new version.
In the new version, SharpJS is used instead of Thumbor API calls.
You can check the new version and download it from here.
Even though you are able to construct urls in old style, images in subfolders are not possible to access anymore without encoding the url.
Old way:
abcdef.cloudfront.net/team/team1.png
New way:
abcdef.cloudfront.net/{base64encodedPath}
Note 1: If your images are in the root directory of the bucket, you are still able to access them old style like this:
abcdef.cloudfront.net/team1.png
Note 2: If you update your existing CloudFormation stack, you will have your old cloudfront domain (which is a good part).
You can also follow the current fixes from here.