Closed jnreynoso closed 6 years ago
The problem might be context.callbackWaitsForEmptyEventLoop = false
. This will freeze the Lambda even if there are still HTTP callbacks pending or if Sentry/Raven still has some notifications in the queue. We have the exact same problem and unfortunately there's no easy way to solve this. See this feature request for raven-node: https://github.com/getsentry/raven-node/issues/338
For us internally this isn't a big deal, however, as typically the errors will be sent on next invocation of the Lamdba. Yes, sounds a bit weird, but if the error is still queued somewhere there's a good chance that it still sends as expected in the subsequent Lambda call. You can test this by hitting your endpoint multiple times without redeploying in between. The errors should arrive eventually.
Hello @arabold.
I'm using context.callbackWaitsForEmptyEventLoop = false
, because if necessary when you work with sequelize. I tried to test what he told me in another function in which I do not use calbackWait ...
and the mistakes did not come, although I called him multiple times (endpoint).
it's a bit frustrating ,thanks for your help @arabold.
I have found that the context.callbackWaitsForEmptyEventLoop = false
option does not even seem to be working with this library, due to the fact that internally the library clones context
before passing it to the handler parameter.
As a result, setting the property doesn't percolate back up to the true AWS context.
To workaround, I am currently doing something like this:
const wrapperWrapper = (handler) => (event, context, callback) => {
context.callbackWaitsForEmptyEventLoop = false;
return handler(event, context, callback);
};
and then wrapping THIS around the library wrapper. I might try to put together a PR to fix this issue.
Oh, that's an interesting problem! I never noticed this issue because we're setting callbackWaitsForEmptyEventLoop
outside of the RavenLambdaWrapper.handler
. But you're right, if you try to set it inside of the wrapped function, it will not work as expected.
Thanks for the PR. I'm gonna review it and add my thoughts.
hi @arabold I have the same problem and I managed to fix that problem with the following code
function shallowClone(obj) {
var clone = Object.create(Object.getPrototypeOf(obj));
var props = Object.getOwnPropertyNames(obj);
props.forEach(function(key) {
var desc = Object.getOwnPropertyDescriptor(obj, key);
Object.defineProperty(clone, key, desc);
});
return clone;
}
const wrappedCtx = shallowClone(context);
// you have that done with extend which doesn't clone callbackWaitsForEmptyEventLoop properly (it's a setter and getter)
// const wrappedCtx = _.extend({}, context);
are you going to provide any fix for this issue? can you provide an example of your function where allbackWaitsForEmptyEventLoop is outside of the RavenLambdaWrapper.handler?
I've just published v1.0.1. It would be great if you can give it a shot!
@timmyers Could you post an example on how you were able to wrap your solution around this library's wrapper?
serverless-sentry-lib works for me in develop but not in production, my configuration of serverless.yml:
verify that the DSN is correct and that the issues are coming to me (local environment), but the mistakes that I am generating in production do not arrive
Generate Error:
Packaje.json