From 1246fae6402187c3ebc6979725095ac9c38bb40a Mon Sep 17 00:00:00 2001 From: Xinyi Ye Date: Thu, 21 Sep 2023 16:40:15 -0700 Subject: [PATCH] update browser debugging (#959) * update browser debugging * Edits * Update includes/sdk-troubleshooting-and-debugging/browser.md Co-authored-by: Alyssa Yu --------- Co-authored-by: Mark Zegarelli Co-authored-by: Alyssa Yu --- .../sdk-troubleshooting-and-debugging/browser.md | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/includes/sdk-troubleshooting-and-debugging/browser.md b/includes/sdk-troubleshooting-and-debugging/browser.md index 661db5f17..296310d62 100644 --- a/includes/sdk-troubleshooting-and-debugging/browser.md +++ b/includes/sdk-troubleshooting-and-debugging/browser.md @@ -61,8 +61,14 @@ Cross-origin resource sharing (CORS) prevents a malicious site from reading anot If you have set up an API proxy and run into configuration issues related to that on a platform you’ve selected, that’s no longer an SDK issue but an integration issue between your application and the service provider. -##### Event Dropping When Closes the Browser or Leaves the Page +##### Events fired but no network requests + +If you [set the logger to "Debug" level](./#debug-mode), and see track calls in the developer console, the `track()` method has been called. If you don't see the corresponding event in Amplitude, the Amplitude Instrumentation Explorer Chrome extension, or the network request tab of the browser, the event wasn't sent to Amplitude. Events are fired and placed in the SDK's internal queue upon a successful `track()` call, but sometimes these queued events may not send successfully. This can happen when an in-progress HTTP request is cancelled. For example, if you close the browser or leave the page. + +There are two ways to address this issue: + +1. If you use standard network requests, set the transport to `beacon` during initialization or set the transport to `beacon` upon page exit. `sendBeacon` doesn't work in this case because it sends events in the background, and doesn't return server responses like `4xx` or `5xx`. As a result, it doesn't retry on failure. `sendBeacon` sends only scheduled requests in the background. For more information, see the [sendBeacon](./#use-sendbeacon) section. + +2. To make track() synchronous, [add the `await` keyword](./#callback) before the call. -If you're using standard network requests, scheduled requests might be dropped if the user closes the browser or leaves the page. To solve this issue, you might want to set the transport to `beacon` during initialization or set the transport to `beacon` upon page exit. However, because `sendBeacon` will send events in the background, it doesn't return server responses and thus cannot retry on failure responses like 4xx or 5xx errors. Also, note that only scheduled requests will be sent out in the background with a `sendBeacon` configuration. -Please refer to the [sendBeacon](./#use-sendbeacon) section for more instructions.