I'm encountering a weird error when one of my Lambda functions is invoked. I have never seen this error. Google searches haven't helped at all. Here's what it looks like :
Ingestion server error
{
"request": {
"url": "https://core.serverless.com/ingestion/kinesis/v1/request-response",
"headers": {
"accept-encoding": "gzip",
"content-type": "application/json",
"serverless_token": "[redacted]"
}
},
"response": {
"status": 500,
"text": "{\"message\":\"Something went wrong forwarding RequestResponseEvent data.\"}"
}
}
I'm pretty sure this has nothing to do with my code since my function works. Occasionally though, for periods of up to about an hour, my function fails with this error. Looking at the error it seems that the Serverless Framework is trying to redirect some data to their servers, for some reason, and failing in the process.
Why is this happening? What is Serverless trying to achieve? What can I do to stop this error from happening? I'm desperate for any insight.
I've also stumbled upon some environment variables that Serverless seems to be setting automatically :
Key
Value
AWS_LAMBDA_EXEC_WRAPPER
/opt/otel-extension/internal/exec-wrapper.sh
OTEL_RESOURCE_ATTRIBUTES
sls_service_name=ODAC-API,sls_stage=dev,sls_org_id=[redacted]
SLS_OTEL_REPORT_LOGS_URL
https://core.serverless.com/ingestion/kinesis/v1/logs
SLS_OTEL_REPORT_METRICS_URL
https://core.serverless.com/ingestion/kinesis/v1/metrics
SLS_OTEL_REPORT_REQUEST_HEADERS
serverless_token=[redacted]
SLS_OTEL_REPORT_REQUEST_RESPONSE_URL
https://core.serverless.com/ingestion/kinesis/v1/request-response
SLS_OTEL_REPORT_TRACES_URL
https://core.serverless.com/ingestion/kinesis/v1/traces
SLS_OTEL_USER_SETTINGS
{}
I have no idea what these are for but it seems related (same url).
Could it have something to do with the sls --console command that I ran? Has it setup some mechanisms to monitor my functions? If so, how can I undo this?
This is really bugging me. Google seems to know nothing of this error, whatever I try to search. Has anyone encountered this before?
This appears to be a backend error coming from the Serverless.com's API.
My guess is you can set console: false in your serverless.yml file and then re-deploy your service to remove the instrumentation - but I haven't confirmed that, it seems absent from their documentation
Related
I need to set up a simple replication schema with a secondary database. I figured out that using arangosh I can set it up with the following commands:
db._useDatabase("myDB");
require("#arangodb/replication").setupReplication({
endpoint: "tcp://main-server:8529",
username: "user",
password: "pass",
verbose: false,
includeSystem: false,
incremental: true,
autoResync: false,
autoStart: true,
restrictType: "include",
restrictCollections: [ "Products" ]
});
This setup, however does not seem to persist. Connection going down, or server restarts make it disappear.
So, I would like to set up some monitoring and re-establishment of the replication in my Go program.
I searched both the ArangoDB website Manual pages, and Go driver documentation but I could not find anything that would allow me to run the above setup in Go using the driver.
Additionally, I didn't find how I could interface with arangosh, and possibly run the JS code above and get the results. Is that possible somehow using the Go driver?
I accidentally found a solution to this.
The Golang driver does not provide this functionality. But Arango has a pretty simple HTTP based API which allows access to all functions and features of the database engine.
Here's the link to the documentation I used: https://www.arangodb.com/docs/3.8/http/index.html
(I'm using version 3.8 because after that the type of replication I needed was no longer part of the community edition).
Setting up a replication requires just two steps:
PUT request to the /_db/yourDBname/_api/replication/applier-config with a JSON payload:
{
"endpoint":"tcp://serverIP:8529",
"database":"yourDBname",
"username":"root",
"password":"password",
"autoResync": true,
"autostart":true
}
And another PUT request to get the replication actually started, to /_db/yourDBname/_api/replication/applier-start . This one doesn't need any payload
And to see how things are going you can do a GET request to /_db/yourDBname/_api/replication/applier-state
All these requests need a JWT token that you can get with a POST request to /_open/auth with a payload of:
{
"username": "user",
"password": "passwd"
}
The token you receive will need to be included in the HTTP header as a bearer token. Pretty simple.
I tried to update the due date with rest API call out but is not updating on google and there is no error and exception for that too.
I tried this from google developer console but it is not updating on google and there is no error too.
It looks like if you do not add the id on the Body you get a 400 response error, it shouldn't be like this, but this should definitely work:
{
"due": "2019-12-25T00:00:00.000Z",
"id": "ekFnZHl5eGt0MG5oaFZZQg"
}
Hi Experts,
I am following https://open.sap.com/courses/s4h13/items/258qEhXx5kdG8b4SXMSJYp tutorial, after deploying the app I am getting 404 for my servlets in approuter application while same servets are giving me 'http 401' in 'address-manager' as expected.
has anyone done this successfully? if so then please guide me in the right direction.
I have gone through everything I could think of, but I can't get past this issue.
xs-app.json file content
{
"welcomeFile": "index.html",
"routes": [
{
"source": "^/api/(.*)",
"target": "/api/$1",
"destination": "app-destination"
},
{
"source": "^/address-manager/(.*)",
"target": "/address-manager/$1",
"destination": "app-destination"
}],
"logout" : {
"logoutEndpoint": "/logout",
"logoutPage": "/logout.html"
}
}
The destinations environment variable of the approuter on SAP Cloud Platform, Cloud Foundry needs to reference the URL(s) at which you reach the application(s) that you want to access via the route(s) defined in the approuter. (Not to be confused with the destinations environment variable that you may be using as a placeholder in athe backend application built with the SAP S/4HANA Cloud SDK.)
In your case, this should probably be some URL pointing to the address-manager, your target application. In the example value mentioned in your comment, you point to the mock server instead, which is probably not what you want.
Change the destinations environment variable to the following and push / restart the application again. (Insert the URL that points to your address manager application deployment.)
[{"name":"app-destination", "url" :"address-manager-<random text>.cfapps.eu10.hana.ondemand.com/", "forwardAuthToken": true}]
The fact that you can login and logout despite the misconfigured destination is expected, because those paths are actually served by the approuter itself.
I have a Lambda function, attached to an API Gateway endpoint, that lists the items under an ID in DynamoDB.
I've built my function using the Serverless Framework. When I invoke the function locally (serverless invoke local ...) it works fine. When I test it manually on the AWS Lambda console, it works fine, but when I call it from the API Gateway, it doesn't work.
It's configured to use this payload: (What I've used for testing)
{
"requestContext": {
"identity": {
"cognitoIdentityId": "468648c5-b135-4075-910a-8a648d66e67d"
}
}
}
In my app, I use the aws-amplify package. This is how I call the endpoint:
data = await API.get('endpoint-name', '/endpoint', {
body: {
requestContext: {
cognitoIdentityId: '468648c5-b135-4075-910a-8a648d66e67d'
}
}
});
Here, I get a 403 error. If I call it without the extra data, i.e:
data = await API.get('endpoint-name', '/endpoint');
I get an empty list [ ], but no error. Does aws-amplify automatically populate the cognitoIdentityId field? I'm following the serverless-stack tutorial, and they kinda gloss over this.
I also have CloudWatch set up, and I cannot see anything funky there. Any ideas on how to fix / debug this issue?
Cheers!
Ah - I think I solved it!
I configured my endpoint to take parameters from the body of a GET request, however (I think) either aws-amplify or the API Gateway doesn't support a request body when performing a GET. I noticed this by manually testing the API Gateway (Which I hadn't done before), and it stated Request Body is not supported for GET methods.
So I think I'll have to pass my parameters in the URL itself.
I followed the step-by-step guide here.
I made a simple app that posts a message to the rooms the Integration is installed on per a regex (as described in the tutorial above).
When I initially add the Integration to a hipchat room, it works fine. However, after a period of time it stops working.
The following error appears in my Heroku logs:
JWT verification error: 400 Request can't be verified without an OAuth secret
I assume something with my configuration is wrong or my lack-of-use-of-OAuth, but after googling around I can't find any specific answers on what it should look like.
My config.json looks like this:
"production": {
"usePublicKey": true,
"port": "$PORT",
"store": {
"adapter": "jugglingdb",
"type": "sqlite3",
"database": "store.db"
},
"whitelist": [
"*.hipchat.com"
]
},
And my request handler looks like this:
app.post('/foo',
addon.authenticate(),
function (req, res) {
hipchat.sendMessage(req.clientInfo, req.identity.roomId, 'bar')
.then(function (data) {
res.sendStatus(200);
});
}
);
Any specific direction on configuration and use of Oauth for Hipchat and Heroku would be amazing!
I personally haven't used the jugglingdb adapter with Heroku and don't know if you can actually look into the database, but it seems like somewhere along the way clientInfo disappears from the store.
My suggestion is to start testing locally with ngrok and redis, so that you can troubleshoot locally and then push the working code to Heroku.
Three things I needed to do in order to fix my problem:
Install the Heroku Redis add-on for my Heroku App. (confirm that the Environment Variable for ($REDIS_URL) was added to your app settings).
Add this line to my app.js file:
ac.store.register('redis', require('atlassian-connect-express-redis'));
Change the production.store object in the config.json to be the following:
"store": {
"adapter": "redis",
"url": "$REDIS_URL"
},