Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for special contexts #33

Open
deepxg opened this issue Oct 1, 2021 · 2 comments
Open

Support for special contexts #33

deepxg opened this issue Oct 1, 2021 · 2 comments

Comments

@deepxg
Copy link
Contributor

deepxg commented Oct 1, 2021

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.

@dharrigan
Copy link
Collaborator

Hi,

Thank you for your contribution :-) Would you like to show an example of how this might work? Thank you.

@deepxg
Copy link
Contributor Author

deepxg commented Oct 2, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants