Switching to Sentry-Python


#22

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!


#23

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


#24

: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


#25

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


#26

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

#27

Here’s the corresponding issue: 920388508

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


#28

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.


#29

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


#30

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

This forum post is getting too long.


#31

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


#32

Commented on the formdata issue:

Reopened the cookie issue (should we reopen?):