Sentry: Big Python integer values are truncated in UI

[hexchain]

I'm using sentry 8.17 (on-premise docker installation) and most of my clients are Python apps.

It seems that integer values larger than Number.MAX_SAFE_INTEGER are truncated in the UI. API values are correct (looking from cURL, NOT Chrome devtools - which also truncates big numbers).

Example:

#!/usr/bin/env python3

from raven import Client

client = Client('http://[email protected]/123')

try:
    bigint = 2 ** 59 - 1
    1 / 0
except ZeroDivisionError:
    client.captureException()

I also have an old installation (7.7.0, python). It does not seem to have this problem.

[PegasusWang]

Also meet this Problem, Python number is integer
959743134293274624,
but Sentry 8.22.0 shows
959743134293274600

[fozzle]

Also seeing this.

[georgexsh]

it is odds that raven has already serialize int and long(py2) to string: https://github.com/getsentry/raven-python/blob/master/raven/utils/serializer/base.py#L196-L201

[georgexsh]

turns out we have installed an outdated raven version.

[Trane9991]

Same here. Sentry cloud.
Values are truncated even if raw output is chosen on the UI.

[lukeburden]

Just got stung by this as well - big ints overflowing silently and rendering extra info passed along to Sentry to not reliably act as context to objects related to an error.

Ie, ID: 367495654166537882 overflowing and becoming 367495654166537860.

This issue has been open for a long time with no response from Sentry folks. I'm going to follow up with them via support, and I suggest you do the same.

[untitaker]

@lukeburden thanks for raising this via support, definetly seems like a bug on our end. I think you're running into an overflow in the backend though, while the OP is running into truncation in the frontend. Yours was likely introduced in a backend rewrite in 2018.It's hard to determine for us whether a bug affecting Sentry 8 is still relevant.

[lukeburden]

Thanks @untitaker - what happens from here? Are you tracking this particular bug somewhere I can follow along? In the meantime we are considering string encoding the payload before we send it to Sentry, for now. Would you have any suggestions there for the python lib?

[untitaker]

String encoding the particular value you're sending seems like a good
workaround, I am not sure what you mean in terms of recommendation for the
python lib?

We'll provide updates to the public github issue if we make progress on
this bug. I fear that we might overflow in multiple places around the code
base so I am not sure if this is easy to fix at all

On Thu, Apr 16, 2020, 01:09 Luke Burden [e-mail] wrote:

Thanks @untitaker https://github.com/untitaker - what happens from
here? Are you tracking this particular bug somewhere I can follow along? In
the meantime we are considering string encoding the payload before we send
it to Sentry, for now. Would you have any suggestions there for the python
lib?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/getsentry/sentry/issues/5633#issuecomment-614324087,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGMPRMAW35XGDXQ5L6ZJ7LRMY5DTANCNFSM4DQYQ5XA
.

[lukeburden]

String encoding the particular value you're sending seems like a good workaround, I am not sure what you mean in terms of recommendation for the python lib?

Ah, I just meant would there be a proper hook in the Sentry lib that we should do the encoding in -perhaps we can access the data and encode bigints to strings in before_send? We'll work it out, but was hoping you might have a quick recommendation.

[untitaker]

You can do that for specific subsections like extra and contexts in
before_send (the extra key in the event is what you want to traverse).

Thanks for your patience

On Thu, Apr 16, 2020, 23:48 Luke Burden [e-mail] wrote:

String encoding the particular value you're sending seems like a good
workaround, I am not sure what you mean in terms of recommendation for the
python lib?

Ah, I just meant would there be a proper hook in the Sentry lib that we
should do the encoding in -perhaps we can access the data and encode
bigints to strings in before_send? We'll work it out, but was hoping you
might have a quick recommendation.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/getsentry/sentry/issues/5633#issuecomment-614914102,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGMPRLL7RHQONSB5P5MJ5DRM54JHANCNFSM4DQYQ5XA
.

[BYK]

@untitaker - do we have a plan around closing this issue?

[untitaker]

Outside of the people listed here I am not aware of customer complaints about overflows. I do think the bug report is valid but I think the urgency is very low (just because very few people have been hittign the issue)