Add new app context that tells if the app is in the background or foreground

[marandaneto]

This field should be queriable in the discover dashboard.
Today people rely on was active: yes|no but it's not 100% correct and aligned between platforms.
Other option is looking into breadcrumbs, but that is not queriable in the discover dashboard.

We could add a tag but afaik SDKs should not add tags themselves.

in_foreground flag

Preview Give feedback

1. Add In Foreground to App context sentry-dart#1260
   +0
2. Add main flag to threads and in_foreground flag for app contexts sentry-java#2516
   +0
3. feat(context): Add in foreground and is main thread sentry-cocoa#2692
   +0
4. feat(sdk): Add in_foreground to event app context sentry-react-native#2826
   +0

main flag.

Preview Give feedback

1. Add main flag to threads and in_foreground flag for app contexts sentry-java#2516
   +0
2. feat(context): Add in foreground and is main thread sentry-cocoa#2692
   +0

Related issues for surfacing on product:

• Provide "is main thread" attribute #198
• Show new app context for "app was in foreground/background" in event details sentry#44251

[adinauer]

was active tells whether it was main thread

Add to context first then talk to search and storage for features on top of it.

[markushi]

Having looked a bit further into this I think we should introduce a new attribute for this, as the existing ones do not cover this use case.

Existing Protocol

Quoting @marandaneto this issue comment describes the thread attributes best

current: if the thread was scheduled/running or not, as the docs say: A flag indicating whether the thread was in the foreground
crashed: if it was the thread that captured the event, either a message or exception, it's just a bad/legacy naming, it does not mean that this thread threw an exception or crashed the App.

Existing Front End

Here we have a was active label which is shown when thread->current evaluates true, see implementation

[marandaneto]

Yes, it needs to be a new field.
Consider looking into https://www.notion.so/sentry/Thread-isCurrent-UIThread-etc-9ad82725c4af412f950e92acf1e6eba4 and #47 as well.
Ideally, this would be done together, because all the fields are a bit confusing, and adding a new one would make it even more, if not properly named and placed in the right place.

[marandaneto]

@markushi getsentry/develop#728 helps for telling if the thread is the ui thread or not.
I believe that for this issue, it requires also a new field in the app protocol https://develop.sentry.dev/sdk/event-payloads/contexts/#app-context
Transactions don't have threads, and this info would be useful for transactions as well.

[markushi]

As far as I can see we need some front-end changes for this as well:

app.in_foreground
Should automatically be visible, as all unknown keys are handled here, probably should be added to the list of known keys at some point.

thread.main
As far as I can see this needs some more work to appear, both on js front-end and backend.

[marandaneto]

Sentry PR getsentry/sentry#43964

[marandaneto]

UI search keys getsentry/sentry#47446
Docs getsentry/sentry#46183

[marandaneto]

SDKs and BE work is done, the only missing bits now is the FE, to show those properties on the UI.
#198
getsentry/sentry#44251
Since MDX is no more, is there someone that could take this?

[romtsn]

Btw for getsentry/sentry#44251 we already display In Foreground in the contexts section

I guess the question is if we also want to promote it as tag and display in the tags section. If not, we could close the issue

[marandaneto]

The in-foreground label is there, but the issue is still open because of #198
We could either rename the title of this issue, or close and open a new one?

We should not promote anything as a tag, the info is in the event already, and the FE should just display it elsewhere.
That field is already indexed, no need to be a tag.

@kahest what's the approach we should take when everything on our end is done, but it depends on external work? this is a good example, this issue will remain open while the other team doesn't tackle the 2 issues left (FE work only), although they are created under the sentry repo already.

[kahest]

Perfectly fine to close this on our end, no need to change the title IMO. The FE related items are clearly pointed out.

[kahest]

I'll check who can take on the FE tasks