| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
There is a small typo in raven/contrib/tornado/__init__.py.
Should read `positively` rather than `postitively`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Use correct kwarg in handle_exception() for Flask
The handle_exception() method is registered as a receiver of the
got_request_exception signal. According to both the [documentation][1]
and [source code][2] of Flask the got_request_exception signal passes
the exception as `exception` rather than a `exc_info`.
This is likely to have gone unnoticed since captureException() calls
sys.exc_info() in the absence of an exception.
On Python 3 we can use `__traceback__` to explicitly construct the
`exc_info`.
[1]: http://flask.pocoo.org/docs/1.0/api/#flask.got_request_exception
[2]: https://github.com/pallets/flask/blob/1.0.2/flask/app.py#L1732
* doc: Add changelog
|
| |
|
|
|
|
|
| |
TypeError: __init__() got multiple values for keyword argument 'transport'
Because it has `get()`ing the 'transport' keyword, instead of `pop()`ing it.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
signal, resolves #961
|
|
|
|
|
|
|
|
|
|
| |
* fix error django VERSION remark
Applications
New in Django 1.7.
https://docs.djangoproject.com/en/1.8/ref/applications/#module-django.apps
|
|
|
|
| |
Fixes:#1127
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Initial lambda integration
* feature(lambda): Add lambda tests and client
* Add D107 to ignore flake8 docs
* Initial lambda integration
* feature(lambda): Add lambda tests and client
* Add reference to raven-python-lambda
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is explicitly choosing to also parse the X-Forwarded-For header to
yank out this value. Otherwise, the Sentry server relies only on the
REMOTE_ADDR value which will always be wrong when when someone is behind
a reverse proxy.
This logic already exists in some other clients, and this has been
brought up a number of times with users via tickets and support.
Worth noting that it's potentially possible for this value to now be
forged from a user, but the ramification of doing so is so low, it's not
worth putting this behavior behind a feature flag IMO. The worst someone
could do is make some data inside Sentry inaccurate and possibly
confusing. No worse than the current state of the world where the data
is completely inaccurate.
|
|
|
|
| |
Fixes #1013 (honest!)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add DjangoRestFrameworkCompatMiddleware
* Update DjangoRestFrameworkCompatMiddleware to not require get_response in constructor
This is for compatibility with Django 1.10 and earlier
* Add unit tests for DjangoRestFrameworkCompatMiddleware
* Update docstring in install_middleware function
* Convert DjangoRestFrameworkCompatMiddleware to be backwards-compatible
* Make sure that middlewares are not set in test_request_data_unavailable_if_request_is_read
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* fix(flask): Add app.logger instrumentation
Older versions of flask set app.logger.propagate to False,
and it's reasonable to expect that users except app.logger
to be instrumented if explictly setting logger=True in the
sentry client.
Fixes: PY-RAVEN #1030 app.logger log call messages are not send to
sentry
* Fix indentation
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The first stab at this was cribbed off the zope integration. This is
now a bit cleaner.
|
| |
|
| |
|
|
|
|
|
|
|
| |
http://zconfig.readthedocs.io/en/latest/using-logging.html
(Note that the Zope integration also uses ZConfig, but adds lots of
Zope-specific machinery that won't work elsewhere.)
|
|
|
|
|
|
|
| |
I've been finding that ``SoftTimeLimitExceeded`` exceptions have not been grouped in the Sentry UI as I would have expected. I believe I have traced it down to the line changed in this pull request. They seemed to occasionally stop form new groups for non-obvious reasons.
After looking around, it seems that ``sender`` (presumably a task instance) includes an object ID in its string representation. As a result, the fingerprint would be different for every celery worker process.
This change will attempt to use the full task name (i.e. ``"my.app.tasks.do_it"``) before falling back to the original implementation.
|
|\
| |
| | |
Handle ignore_exceptions values being class or string
|
| | |
|
| | |
|
|/
|
|
|
|
|
| |
- utilize app.ready() for Django 1.7+
- ensure client is instantiated upon initialization (fixes sys.except_hook)
Fixes GH-884
|
| |
|
|
|
|
|
|
| |
- expand tests to cover basic tastypie
- correct leaking of request local in middleware
- improve django test fundamentals
|
| |
|
| |
|
| |
|
| |
|
|
|
| |
In zope.conf's configuration spec, which will be passed on and processed by Raven.
|
| |
|
|
|
|
|
|
| |
`six` wasn't vendored into Django until 1.5, so this explicitly is
breaking support for 1.4. We already have this function vendored, so
might as well use our copy instead.
|
|
|
|
|
|
|
|
|
|
|
|
| |
In a Django HttpRequest object, the request data is a QueryDict object,
which is a dictionary-like class that supports multiple values for the
same key. This is used, for instance, with <select multiple> form
elements.
In order to have the request data serialize into JSON correctly when
there are multiple values, it is necessary to use QueryDict.iterlists() /
QueryDict.lists() (python 2 and 3, respectively). Otherwise, the value
passed to Sentry will contain only the last value in the query string.
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Add Flask-specific builds
- Add Celery-specific builds
- Restore Django dev build
- Reduce Django builds to only focus on subset of versions
- Expand norecursedirs
- Drop Python 2.6 support (as deps are starting to)
- Update pytest-django
- Limit django-celery exposure
- Correct django-celery 3.1 behavior
|