You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now the context code lets you specify extra keys and values, and has a hard coded representation. However there are various special keys that Sentry supports (e.g. the "os" key) which display slightly more nicely in the Sentry UI. In the underlying Java library these have explicit classes to represent them.
I'm wondering if there's any interest in supporting these special keys better. One drawback would be that changing the way these keys are handled would change the data sent to the server and therefore potentially break people's existing setups, so it'd need to be opt in.
The text was updated successfully, but these errors were encountered:
So if you have a look at the Java code or the Sentry docs, you can see that there's basically some special cases with meaningful key value pairs underneath them. I will accept it's mainly my OCD driving this, but these are all in some way blessed in the web UI so they get nicer display in incident reports. Right now the Clojure context forces everything under a context to be nested under a :value key. My suggestion is that for the special cases supported by the Java client at least, we format things the official way for known keys. As I say, this is probably a breaking change for most people so might need to be opt in.
Without this, you're forced to basically replicate the Sentry/configureScope code to have control over the actual keys and values.
Right now the context code lets you specify extra keys and values, and has a hard coded representation. However there are various special keys that Sentry supports (e.g. the "os" key) which display slightly more nicely in the Sentry UI. In the underlying Java library these have explicit classes to represent them.
I'm wondering if there's any interest in supporting these special keys better. One drawback would be that changing the way these keys are handled would change the data sent to the server and therefore potentially break people's existing setups, so it'd need to be opt in.
The text was updated successfully, but these errors were encountered: