From 0a17a55e9637900144ff822df5de038979b0a751 Mon Sep 17 00:00:00 2001 From: Dhiogo Brustolin Date: Fri, 22 Apr 2022 09:24:09 +0200 Subject: [PATCH 1/6] Updates screenshot feature detail --- src/docs/sdk/features.mdx | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/docs/sdk/features.mdx b/src/docs/sdk/features.mdx index 8dd0b76e6a..da72501353 100644 --- a/src/docs/sdk/features.mdx +++ b/src/docs/sdk/features.mdx @@ -151,7 +151,8 @@ It's advised to provide this feature through a single option called `attachScree The feature is achieved by adding an attachment with: -* File name `screenshot.jpg` or `screenshot.png` +* File name `screenshot.jpg` or `screenshot.png` + * Subsequent screenshots in the same event should be named `screenshot-n`, where n is the screenshot number starting with 2 * Image size, if possible should stay below 2 MB but quality/size could be configurable * `ContentType: image/jpg` or `ContentType: image/png` From 10af9362e7535b78643141685345c5e8108f0271 Mon Sep 17 00:00:00 2001 From: Dhiogo Brustolin Date: Mon, 25 Apr 2022 12:03:53 +0200 Subject: [PATCH 2/6] Update features.mdx --- src/docs/sdk/features.mdx | 1 + 1 file changed, 1 insertion(+) diff --git a/src/docs/sdk/features.mdx b/src/docs/sdk/features.mdx index da72501353..ce99c6420e 100644 --- a/src/docs/sdk/features.mdx +++ b/src/docs/sdk/features.mdx @@ -147,6 +147,7 @@ When the user opts-in, if technically possible, take a screenshot of the applica This feature only applies to SDKs with a user interface, such as Mobile and Desktop. In some environments such as native iOS, taking a screenshot requires the UI thread and in the event of a crash, that might not be available. So inherently this feature will be a best effort solution. +Also, some environments don`t allow access to the UI or some features during a hard crash, iOS for example, doesn't allow running Objective-c code after a signal break, therefore no hard crash screenshot capture will be possible. It's advised to provide this feature through a single option called `attachScreenshot`. That's the preferred way but in platforms such as Flutter, a wrapping widget is required so documentation can point users to that instead of the suggested option name. The feature is achieved by adding an attachment with: From 5f29fd273a4685104272c180123584c975600b84 Mon Sep 17 00:00:00 2001 From: Dhiogo Brustolin Date: Mon, 25 Apr 2022 13:48:46 +0200 Subject: [PATCH 3/6] Update src/docs/sdk/features.mdx Co-authored-by: Manoel Aranda Neto <5731772+marandaneto@users.noreply.github.com> --- src/docs/sdk/features.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/docs/sdk/features.mdx b/src/docs/sdk/features.mdx index ce99c6420e..fb385f07c5 100644 --- a/src/docs/sdk/features.mdx +++ b/src/docs/sdk/features.mdx @@ -147,7 +147,7 @@ When the user opts-in, if technically possible, take a screenshot of the applica This feature only applies to SDKs with a user interface, such as Mobile and Desktop. In some environments such as native iOS, taking a screenshot requires the UI thread and in the event of a crash, that might not be available. So inherently this feature will be a best effort solution. -Also, some environments don`t allow access to the UI or some features during a hard crash, iOS for example, doesn't allow running Objective-c code after a signal break, therefore no hard crash screenshot capture will be possible. +Also, some environments don`t allow access to the UI or some features during a hard crash, iOS, for example, doesn't allow running Objective-C code after a signal break, therefore no hard crash screenshot capture will be possible. It's advised to provide this feature through a single option called `attachScreenshot`. That's the preferred way but in platforms such as Flutter, a wrapping widget is required so documentation can point users to that instead of the suggested option name. The feature is achieved by adding an attachment with: From 032b3475d66a65997cb12616a17a6a5e4e252a5f Mon Sep 17 00:00:00 2001 From: Dhiogo Brustolin Date: Tue, 26 Apr 2022 12:25:19 +0200 Subject: [PATCH 4/6] Update features.mdx --- src/docs/sdk/features.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/docs/sdk/features.mdx b/src/docs/sdk/features.mdx index fb385f07c5..2b37c81326 100644 --- a/src/docs/sdk/features.mdx +++ b/src/docs/sdk/features.mdx @@ -143,7 +143,7 @@ useful because attachments could quickly eat up the users' disk space. Furthermo ## Screenshots -When the user opts-in, if technically possible, take a screenshot of the application and include as an [attachment](#attachments) to the [envelope](/sdk/envelopes/) with the event. +When the user opts-in, if technically possible, take a screenshot of the application during a crash or error and include it as an [attachment](#attachments) to the [envelope](/sdk/envelopes/) with the event. This feature only applies to SDKs with a user interface, such as Mobile and Desktop. In some environments such as native iOS, taking a screenshot requires the UI thread and in the event of a crash, that might not be available. So inherently this feature will be a best effort solution. From ce6cc2404a044a002e781055dd34b60013bee10b Mon Sep 17 00:00:00 2001 From: Philipp Hofmann Date: Mon, 25 Apr 2022 14:47:22 +0200 Subject: [PATCH 5/6] fix: Document min Sentry version for client reports (#564) --- src/docs/sdk/client-reports.mdx | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/docs/sdk/client-reports.mdx b/src/docs/sdk/client-reports.mdx index b727c7b2e9..1e4ae43657 100644 --- a/src/docs/sdk/client-reports.mdx +++ b/src/docs/sdk/client-reports.mdx @@ -8,6 +8,10 @@ about themselves to Sentry. They are currently mainly used to emit outcomes for events that were never sent. Chained relays are also able to emit these client reports to inform the next relay in chain about _some_ outcomes. +Due to a bug in Relay, which discards envelopes containing unknown envelope +items, the minimum required version of Sentry for client reports is +[21.9.0](https://github.com/getsentry/relay/blob/master/CHANGELOG.md#2190). + ## Basic Operation Client reports are sent as envelope items to Sentry, typically as separate From 716e038783fccc2800c357ffdf8612396c5fdf9b Mon Sep 17 00:00:00 2001 From: Alexander Dinauer Date: Tue, 26 Apr 2022 12:17:07 +0200 Subject: [PATCH 6/6] Document session update for dropped events (#551) * Document session update for dropped events See https://github.com/getsentry/develop/issues/537 and https://github.com/getsentry/sentry-java/issues/1916 Do we also want to document order of the filtering mechanisms? If so do we go with the python implementation order as a template? * Add filter order Python now serves as reference implementations. We've recently changed the order there, see https://github.com/getsentry/sentry-python/pull/1394 and https://github.com/getsentry/sentry-python/pull/1390 * Session update should be sent... ... despite the event being dropped in application mode for certain cases. --- src/docs/sdk/sessions.mdx | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/src/docs/sdk/sessions.mdx b/src/docs/sdk/sessions.mdx index d1c661996a..3204d54b7d 100644 --- a/src/docs/sdk/sessions.mdx +++ b/src/docs/sdk/sessions.mdx @@ -505,3 +505,21 @@ Sessions are never tracked nor sent individually, instead they are aggregated an As an implementation hint to the point above, when a "Client" is closed or flushed the associated "Session Flusher" shall also be flushed and submit the current aggregates the the transport, before the transport is flushed/closed. Make sure this works reasonably for Serverless — there we shall not use "request mode" and SessionFlusher because we cannot have any work that happens outside of the request-response flow. Provide an easy way to integrate with existing Node frameworks (Express, Next.js, Koa). + +### Session update filtering + +Events may be dropped by our filtering mechanisms (sample rate, beforeSend, event processors or ignored exception types). Only events dropped due to sampling should update the session despite being dropped as we assume the event was dropped to save quota but would have been something the developer cares about. Events dropped due to other reasons should not update the session as we assume they are more likely to be dropped because the developer chooses to ignore them. + +#### Filter order + +The python SDK shall serve as a reference here. The order for filtering error events is: +1. Check for ignored exception types (a.k.a `ignore_errors`) +3. Apply scoped `event_processor` (a.k.a `error_processor`) +4. Apply global `event_processor` +2. Apply `before_send` +5. Update the session if an event made it this far +6. Apply sampling rate + +#### Sending the session update + +If the event has been dropped and the session updated, the session update should be sent to the server without the event in case the session changed from healthy to errored or from any state to crashed for user attended sessions.