Repository: getsentry/sentry
Pull request: ref(contexts): Prettify only known contexts - [TET-453]
**Before:**

<img width="1148" alt="image" src="https://user-images.githubusercontent.com/29228205/201894175-e0ccab87-4f1d-40a4-b45f-14e2feea6a54.png">



**After:**

<img width="1133" alt="image" src="https://user-images.githubusercontent.com/29228205/201894221-37a59d91-649d-4686-aeb3-f2a05156aa81.png">



Revert changes merged in the PR https://github.com/getsentry/sentry/pull/35188 so we don't prettify unknown contexts  as we agreed in https://github.com/getsentry/sentry/issues/39450

Closes https://github.com/getsentry/sentry/issues/39450

Problem statement:
sentry_set_context() doesn't display strings correctly
**Description**

I'm using sentry_set_context() to add some settings to crashes. But when the data is displayed in the web UI the strings have been prettified:
Local_settings
Last Position Latitude	38.897957
Last Position Longitude	-77.036560

**When does the problem happen**

<!-- Put an `x` where relevant. -->

- [ ] During build
- [ ] During run-time
- [x] When capturing a hard crash

**Environment**

- OS: ARM Linux
- Compiler: gcc

**Steps To Reproduce**

```
        sentry_value_t local_settings = sentry_value_new_object();
        sentry_value_set_by_key(local_settings, "last_position.latitude", sentry_value_new_double(38.897957));
        sentry_value_set_by_key(local_settings, "last_position.longitude", sentry_value_new_double(-77.036560));
        sentry_set_context("local_settings", local_settings);
```

Hints from issue discussion:
I think this might rather be a UI concern? You might as well stringify the values on the client instead of passing them as `double` values.
I wasn't sure which repo to create UI issues in. Also it's not the values that are the problem, it's the variable names changing from "last_position.latitude" to Last Position Latitude.
oh okay, that is definitely a UI issue then.
Routing to @getsentry/app-frontend for [triage](https://develop.sentry.dev/processing-tickets/#3-triage). ⏲️

Routing to @getsentry/telemetry-experience for [triage](https://develop.sentry.dev/processing-tickets/#3-triage). ⏲️

Hey @parsley72, it's intended behavior that was introduced [here](https://github.com/getsentry/sentry/pull/35188) based on the feedback we've received in the past.

Can you please tell me more about your use case and why you don't like it to be prettified?
I'm reporting values from a JSON settings file to give context to the crash - what options has the user turned on/off? I want the strings to match the JSON rather than being prettified. Ideally there should be a switch for this, either in the UI or at the reporting end.
That's fair, let me add that to our backlog and we'll figure something out. 👍
Alright, a bit more context:

We have:
1. [known, out of the box, contexts](https://github.com/getsentry/sentry/blob/e332e01a33d5b75b32e78fa87ebedd4a866110e7/static/app/components/events/contexts/utils.tsx#L14) like browser, device, app, os, etc.
2. And unknown contexts that users can set themselves via SDK.

For keys of known contexts, we have formatters in UI to make them look nice. [example for known key of known context](https://github.com/getsentry/sentry/blob/cdfe392ddbfa78c1560f51ce85f0d39c3b42ab00/static/app/components/events/contexts/app/getAppKnownDataDetails.tsx#L21-L63) and [example for unknown key of known context](https://github.com/getsentry/sentry/blob/e332e01a33d5b75b32e78fa87ebedd4a866110e7/static/app/components/events/contexts/utils.tsx#L166-L189)

For keys of unknown contexts, we have this [catch-all rule](https://github.com/getsentry/sentry/blob/a26d73ec525b8ea5a6e96d2b833a1de6a0b0ae05/static/app/components/events/contexts/default.tsx#L17) that transform strings to start case. E.g.`min_worker_threads` -> `Min Worker Threads`.

@bruno-garcia what do you say we change this and have these formatters only for known contexts and leave unknown contexts raw?
I know that in the past there was a concern that every time SDK team adds a new key, they would have to change code in UI. 
How often do we actually add keys to the **unknown** contexts? If it's something SDK support out of the box then it will be known context and there we have formatters for keys, no?
> @bruno-garcia what do you say we change this and have these formatters only for known contexts and leave unknown contexts raw?
I know that in the past there was a concern that every time SDK team adds a new key, they would have to change code in UI.
How often do we actually add keys to the unknown contexts? If it's something SDK support out of the box then it will be known context and there we have formatters for keys, no?

Yeah that's probably a good trade off. Another option is a toggle between raw and captitalized

Commit message: ref(contexts): Prettify only known contexts

Patch to review:
diff --git a/static/app/components/events/contexts/default.tsx b/static/app/components/events/contexts/default.tsx
index 8ecd3348b152ef..4af0406374a4d9 100644
--- a/static/app/components/events/contexts/default.tsx
+++ b/static/app/components/events/contexts/default.tsx
@@ -1,5 +1,3 @@
-import startCase from 'lodash/startCase';
-
 import ContextBlock from 'sentry/components/events/contexts/contextBlock';
 import {Event} from 'sentry/types/event';
 
@@ -14,7 +12,7 @@ function getKnownData(data: Props['data']) {
     .filter(([k]) => k !== 'type' && k !== 'title')
     .map(([key, value]) => ({
       key,
-      subject: startCase(key),
+      subject: key,
       value,
     }));
 }
diff --git a/static/app/components/events/contexts/operatingSystem/index.spec.tsx b/static/app/components/events/contexts/operatingSystem/index.spec.tsx
index 552dab09aa67b9..cb360363816beb 100644
--- a/static/app/components/events/contexts/operatingSystem/index.spec.tsx
+++ b/static/app/components/events/contexts/operatingSystem/index.spec.tsx
@@ -45,7 +45,7 @@ describe('operating system event context', function () {
       },
     });
 
-    expect(screen.getByText('Raw Description')).toBeInTheDocument(); // subject
+    expect(screen.getByText('raw_description')).toBeInTheDocument(); // subject
     userEvent.hover(screen.getByText(/redacted/));
     expect(
       await screen.findByText(
diff --git a/static/app/components/events/contexts/utils.spec.tsx b/static/app/components/events/contexts/utils.spec.tsx
index c13d998caedc8a..a7c5e1952b0ad9 100644
--- a/static/app/components/events/contexts/utils.spec.tsx
+++ b/static/app/components/events/contexts/utils.spec.tsx
@@ -16,8 +16,8 @@ describe('contexts utils', function () {
       const unknownData = getUnknownData({allData, knownKeys});
 
       expect(unknownData).toEqual([
-        {key: 'username', value: 'a', subject: 'Username', meta: undefined},
-        {key: 'count', value: 1000, subject: 'Count', meta: undefined},
+        {key: 'username', value: 'a', subject: 'username', meta: undefined},
+        {key: 'count', value: 1000, subject: 'count', meta: undefined},
       ]);
     });
   });
diff --git a/static/app/components/events/contexts/utils.tsx b/static/app/components/events/contexts/utils.tsx
index 41e1f40ef1ab80..a2811ee6ed1831 100644
--- a/static/app/components/events/contexts/utils.tsx
+++ b/static/app/components/events/contexts/utils.tsx
@@ -1,6 +1,5 @@
 import {Fragment} from 'react';
 import styled from '@emotion/styled';
-import startCase from 'lodash/startCase';
 import moment from 'moment-timezone';
 
 import ContextData from 'sentry/components/contextData';
@@ -183,7 +182,7 @@ export function getUnknownData({
     .map(([key, value]) => ({
       key,
       value,
-      subject: startCase(key),
+      subject: key,
       meta: meta?.[key]?.[''],
     }));
 }


Code review comments:
diff_hunk: @@ -183,7 +182,7 @@ export function getUnknownData({
     .map(([key, value]) => ({
       key,
       value,
-      subject: startCase(key),
+      subject: key,
path: static/app/components/events/contexts/utils.tsx
text: @user1:
I don't think we should change it here. This one formats unknown keys for known contexts. Those we want to keep pretty.

@author:
do you mean context sections? `app`, `device`, `browser`, `os`, `runtime`, `gpu`, `trace`, etc?


@user1:
yes

@author:
I see.. it makes sense... it felt weird to have the both pattern in one section