From b9ad701dadc28cfb7c9f728704d5d0646da6b102 Mon Sep 17 00:00:00 2001 From: Markus Hintersteiner Date: Mon, 7 Apr 2025 12:28:37 +0200 Subject: [PATCH 1/2] chore(sdk): Clarify HTTP response codes considered successful --- develop-docs/sdk/expected-features/index.mdx | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/develop-docs/sdk/expected-features/index.mdx b/develop-docs/sdk/expected-features/index.mdx index 40808be4f5a6d..9167601dfa3a6 100644 --- a/develop-docs/sdk/expected-features/index.mdx +++ b/develop-docs/sdk/expected-features/index.mdx @@ -232,16 +232,17 @@ This feature is also known as 'Offline Caching'. Write events to disk before attempting to send, so that they can be retried in the event of a temporary network failure. Needs to implement a cap on the number of stored events. This is mostly useful on mobile and desktop(e.g: laptop) apps, where stable connectivity is often not available. -#### Dealing with failures +### Dealing with network failures -It's important to note that retry is only considered in the event of a network failure. For example: +A `HTTP 2xx` response status code response from Sentry is considered a successful send. It's important to note that retry is only considered in the event of a network failure. For example: * Connection timeout * DSN resolution failure * Connection reset by peer Other failures, like those caused by processing the file in the SDK itself, the payload should be discarded since those are likely to end up on an endless retry. -If the event reached Sentry and a HTTP response status code was received, even in the event of a `500` response, the event should be discarded. +If the event reached Sentry and a HTTP response status code was received, even in the event of a `HTTP 500` status code, the event should be discarded. + #### Additional capabilities From 9e6b076fd13938c5ddf1cace5b1e5435248f54d5 Mon Sep 17 00:00:00 2001 From: Markus Hintersteiner Date: Wed, 23 Apr 2025 13:49:27 +0200 Subject: [PATCH 2/2] Apply suggestions from code review Co-authored-by: Alex Krawiec --- develop-docs/sdk/expected-features/index.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/develop-docs/sdk/expected-features/index.mdx b/develop-docs/sdk/expected-features/index.mdx index 9167601dfa3a6..44536cbc45204 100644 --- a/develop-docs/sdk/expected-features/index.mdx +++ b/develop-docs/sdk/expected-features/index.mdx @@ -232,16 +232,16 @@ This feature is also known as 'Offline Caching'. Write events to disk before attempting to send, so that they can be retried in the event of a temporary network failure. Needs to implement a cap on the number of stored events. This is mostly useful on mobile and desktop(e.g: laptop) apps, where stable connectivity is often not available. -### Dealing with network failures +### Dealing With Network Failures -A `HTTP 2xx` response status code response from Sentry is considered a successful send. It's important to note that retry is only considered in the event of a network failure. For example: +An `HTTP 2xx` status code response from Sentry is considered a successful send. It's important to note that retry is only considered in the event of a network failure. For example: * Connection timeout * DSN resolution failure * Connection reset by peer Other failures, like those caused by processing the file in the SDK itself, the payload should be discarded since those are likely to end up on an endless retry. -If the event reached Sentry and a HTTP response status code was received, even in the event of a `HTTP 500` status code, the event should be discarded. +If the event reached Sentry and an HTTP response status code was received, even in the event of an `HTTP 500` status code, the event should be discarded. #### Additional capabilities