Open jcerjak opened 7 years ago
If we truly cant use the threaded transport, then this seems like an easy fix in the discovery (the env check)
Not sure why it doesn't work, maybe I'm doing something wrong..
Steps to reproduce the issue
import os
from raven import Client
client = Client(os.environ['SENTRY_DSN'])
@client.capture_exceptions def lambda_handler(event, context): raise Exception('Error!')
2. Package the lambda for Python 2.7 as per [AWS instructions](http://docs.aws.amazon.com/lambda/latest/dg/lambda-python-how-to-create-deployment-package.html), together with dependencies (raven==6.1.0 and contextlib2==0.5.5). I've built the package in the [AWS environment](http://docs.aws.amazon.com/lambda/latest/dg/current-supported-versions.html), though in this case it probably doesn't make a difference, since there are no C extensions.
3. Deploy the lambda package to AWS, with Python 2.7 environment. Set SENTRY_DSN environment variable (`https://...`)
4. Trigger the lambda. No errors are logged in Sentry.
5. Replace the lambda code with:
import os from raven import Client from raven.transport.http import HTTPTransport
client = Client(os.environ['SENTRY_DSN'], transport=HTTPTransport)
@client.capture_exceptions def lambda_handler(event, context): raise Exception('Error!')
6. Trigger the lambda again. Now the error should show up in Sentry.
Im porting https://github.com/Netflix-Skunkworks/raven-python-lambda to raven, but in the meanwhile you can Check out their implementation. On Wed, 23 Aug 2017 at 12:08, Jure Cerjak notifications@github.com wrote:
Not sure why it doesn't work, maybe I'm doing something wrong..
Steps to reproduce the issue
- Create a lambda function with content:
import os from raven import Client
client = Client(os.environ['SENTRY_DSN'])
@client.capture_exceptions def lambda_handler(event, context): raise Exception('Error!')
- Package the lambda for Python 2.7 as per AWS instructions http://docs.aws.amazon.com/lambda/latest/dg/lambda-python-how-to-create-deployment-package.html, together with dependencies (raven==6.1.0 and contextlib2==0.5.5). I've built the package in the AWS environment http://docs.aws.amazon.com/lambda/latest/dg/current-supported-versions.html, though in this case it probably doesn't make a difference, since there are no C extensions.
- Deploy the lambda package to AWS, with Python 2.7 environment. Set SENTRY_DSN environment variable (https://...)
- Trigger the lambda. No errors are logged in Sentry.
- Replace the lambda code with:
import os from raven import Client from raven.transport.http import HTTPTransport
client = Client(os.environ['SENTRY_DSN'], transport=HTTPTransport)
@client.capture_exceptions def lambda_handler(event, context): raise Exception('Error!')
- Trigger the lambda again. Now the error should show up in Sentry.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/getsentry/raven-python/issues/1063#issuecomment-324284102, or mute the thread https://github.com/notifications/unsubscribe-auth/AAW4tclk1F6JgFPn8szQjDqMPb4-UP3Mks5sa_oZgaJpZM4O-0XS .
It seems that they are also using HTTPTransport: https://github.com/Netflix-Skunkworks/raven-python-lambda/blob/master/raven_python_lambda/__init__.py#L49
If it's purely the default transport that breaks it we should just get that ito core. We also might want to explore if we should only enable threads in certain situations based on feature detect?
SentryHandler does not send errors to sentry when log level is set to ERROR
on Lambda. I'm using dictConfig
to configure logging with this handler, is there something I need to do to get this working?
In AWS Lambda environment,
HTTPTransport
should be used instead of the defaultThreadedHTTPTransport
(this was added in #828). Which HTTP transport to use is determined based on the presence of theLAMBDA_TASK_ROOT
environment variable. But in my caseThreadedHTTPTransport
is used, even thoughLAMBDA_TASK_ROOT
is there.I discovered this when noticing that some of the errors were not being reported to Sentry.
Why this happens?
It seems that when instantiating the
Client
from DSN, the default transport is used, and the one determined by discover_default_transport is ignored.How to fix this?
The
discover_default_transport
should be taken into account when using RemoteConfig.from_string. If this is not acceptable, the docs should mention thattransport
needs to be manually set toraven.transport.http.HTTPTransport
when using Sentry on AWS Lambda.