Switching to Sentry-Python

Thanks, that did the trick. I’ll stick with the “logger” approach for now, but would certainly consider switching JS and Python into separate projects if that’s the recommended approach.

Keep me posted on the cookie fix, which I think was my only outstanding issue!

Hi, 0.7.5 should be released very soon which should solve the cookies issue. Sorry for the wait!

:raised_hands:t2: Installed 0.7.6 and I’m no longer seeing the cookie error… though I don’t think I’m seeing the cookies either:

https://sentry.io/organizations/storyworth/issues/919347283

Hmm, could you turn on init(debug=True) and check the logs? It could be the case that we crashed while extracting request data.

Hmm, not seeing any crashes.

9:27:46 AM web.1 |   [sentry] DEBUG: Setting up integrations (with default = True)
9:27:46 AM web.1 |   [sentry] DEBUG: Setting up previously not enabled integration tornado
9:27:46 AM web.1 |   [sentry] DEBUG: Setting up previously not enabled integration logging
9:27:46 AM web.1 |   [sentry] DEBUG: Setting up previously not enabled integration stdlib
9:27:46 AM web.1 |   [sentry] DEBUG: Setting up previously not enabled integration excepthook
9:27:46 AM web.1 |   [sentry] DEBUG: Setting up previously not enabled integration dedupe
9:27:46 AM web.1 |   [sentry] DEBUG: Setting up previously not enabled integration atexit
9:27:46 AM web.1 |   [sentry] DEBUG: Setting up previously not enabled integration modules
9:27:46 AM web.1 |   [sentry] DEBUG: Setting up previously not enabled integration argv
9:27:46 AM web.1 |   [sentry] DEBUG: Setting up previously not enabled integration threading
9:27:46 AM web.1 |   [sentry] DEBUG: Enabling integration tornado
9:27:46 AM web.1 |   [sentry] DEBUG: Enabling integration logging
9:27:46 AM web.1 |   [sentry] DEBUG: Enabling integration stdlib
9:27:46 AM web.1 |   [sentry] DEBUG: Enabling integration excepthook
9:27:46 AM web.1 |   [sentry] DEBUG: Enabling integration dedupe
9:27:46 AM web.1 |   [sentry] DEBUG: Enabling integration atexit
9:27:46 AM web.1 |   [sentry] DEBUG: Enabling integration modules
9:27:46 AM web.1 |   [sentry] DEBUG: Enabling integration argv
9:27:46 AM web.1 |   [sentry] DEBUG: Enabling integration threading
9:27:47 AM web.1 |   [sentry] DEBUG: Sending error event [201304dfc29744d88c3d00bf13498c23] to app.getsentry.com project:22993
[... TRACE ...]
9:27:47 AM web.1 |  DEBUG:sentry_sdk.errors:Sending error event [201304dfc29744d88c3d00bf13498c23] to app.getsentry.com project:22993

Here’s the corresponding issue: 920388508

(For some reason the forum isn’t letting me post the link to sentry dot io anymore?)

Sorry, that was a bad guess. I’m seeing the following data in the JSON payload in all the issues I’ve checked so far:

"_meta": {
    "request": {
      "cookies": {
        "18": {
          "1": {
            "": {
              "len": 680,
              "rem": [
                [
                  "!limit",
                  "s",
                  182,
                  185
                ]
              ]
            }
          }
        }
      }
    }
  }

I don’t quite understand why there’s a single cookie value that is deemed too large, but this seems like a bug in our serverside trunchation logic. Could you paste how the payload looks at the clientside? The debug=True should cause the SDK to print that to stdout.

Sorry I missed your reply. I’m afraid I’m not seeing any payload info in the client side output.

Separately, it appears that POST variables aren’t being sent either, see this issue:

https://sentry.io/organizations/storyworth/issues/935138080

Could we discuss both issues on GitHub: https://github.com/getsentry/sentry-python

This forum post is getting too long.

:+1:t2: I’ll file an issue there.

Commented on the formdata issue:

Reopened the cookie issue (should we reopen?):

Hey. Thanks for a useful quick migration guide, but I think you’ve got a typo in there.
It seems that scope.capture_message should have been sentry_sdk.capture_message

Thanks, fixed!

Currently, im using the old raven[flask] python package in sentry. What are some of the reasons we should switch to the newer one right now? I don’t think I can find anything describing the differences.

Hmm, migration doesn’t seem as easy as I thought because I don’t see any docs related to these things. Right now, I’m playing too much of a game of having to compare the old vs. the new by looking at the source code (e.g: We have keywords like tags, transport, etc. Also, we’re using a SentryHandler.)

Does Sentry-Python have something like Raven’s SentryHandler? Thanks!

Ref: https://raven.readthedocs.io/en/stable/integrations/logging.html#

+1 for needing Raven’s SentryHandler. My pattern is:

from raven import Client
from raven.handlers.logging import SentryHandler

client = Client(dsn=my_dsn, release=version, environment='PROD', enable_breadcrumbs=False)
handler = SentryHandler(client=client, level=logging.ERROR)

It’s unclear how I would migrate to sentry-python given that.