thread_id is typed as a string but Sentry actually sends ints #767
Comments
|
I can confirm that |
|
It looks like Relay expects an integer as well, /~https://github.com/getsentry/relay/blob/master/relay-event-schema/src/protocol/exception.rs#L89. I think we can make this change. |
|
Glad to hear it @cleptric. For us this is a blocker to using Sentry. When do you see this being fixed? It's a tough one to workaround. |
|
We can get a fix out later this week. |
untitaker
added a commit
to getsentry/relay
that referenced
this issue
Feb 13, 2024
While porting the Snuba consumers to Rust, I saw that thread IDs could be strings. This isn't really aligned with how it's typed in our frontend, typed in symbolicator, and appears to subvert user expectations as well: getsentry/sentry-go#767 It seems easiest to restrict the output type and silently coerce strings to integers. This also gets rid of weird artifacts like people sending in random (non-numerical) strings which is currently allowed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
/~https://github.com/getsentry/sentry-go/blob/master/interfaces.go#L244
^This field,
thread_id, is typed as astringbut Sentry actually sendsints. This is blocking us from deserialising any event from Sentry.This is the only issue with the modelling I've found.
Background:
We have the Android Sentry SDK set up in our app. We've got a Go webhook consuming alert events. These events cannot be deserialised currently because of this bug. Not sure if this problem is somehow specific to
event_alerts coming from a JVM/Android project or not.The text was updated successfully, but these errors were encountered: