Merge branch 'master' of github.com:getsentry/sentry-docs into smi/quick-start/review-nestjs

Author: inventarSarah

.github/CODEOWNERS

@@ -3,9 +3,6 @@
 # Requiring review from security team for Content-Security-Policy changes
 **/vercel.json @getsentry/security
 
-# owners-api is tagged here but anyone can just approve the SHA Bump PRs
-/src/build/resolveOpenAPI.ts @getsentry/owners-api
-
 # Codeowners listed below are used as a reference for the Sentry team to know who to contact for a given area of the codebase.
 
 # /src/platforms/android/ @getsentry/team-mobile-core

develop-docs/backend/application-domains/database-migrations/index.mdx

@@ -565,7 +565,7 @@ Post-deploy migrations are run manually by engineers **after** a migration has b
 Post-deploy migrations are ideal for:
 
 * Adding indexes to large tables, where adding the index would take longer than
-  5 seconds in any given region.
+  10 seconds in any given region.
 * Doing data backfills or mutations on tables with more than 50,000 rows.
 
 Post-deploy migrations **should not** be used for:

develop-docs/integrations/jira/images/jira-setup2.png

@@ -19,23 +19,28 @@ To enable issue-sync between Jira and a locally hosted Sentry Jira integration,
 ## Installing Local Jira App
 
 1. If you don't have any projects in your Jira org yet, create a new project.
+
 2. In the navigation bar at the top of the screen, click on the waffle icon (1), select the desired organization and click "Administration" (2).
 ![Navigating to Administration](./images/jira-setup1.png)
 
 3. In the navigation bar, click "Products" (3) and under "Sites and products" (4) select the appropriate site/product with your Jira project.
 ![Navigating to the Correct Site](./images/jira-setup1.5.png)
 
 4. In the sidebar on the left, click on "Connected apps" (5) and then click on the Settings tab (6).
+
 5. Click on the button labeled "Install a private app" (7).
 ![Navigating to Connected Apps](./images/jira-setup2.png)
 
 6. In the new modal, select JIRA for the product to install the app on (8).
+
 7. For the "App descriptor URL" (9), use the following URL, `https://{YOUR_SENTRY_DOMAIN}/extensions/jira/descriptor/`.
     * Note that if you are running a local devserver, `YOUR_SENTRY_DOMAIN` will be your ngrok (or other tunneling service) domain.
+      * You will also need to keep the local devserver to be running
     * For self-hosted Sentry users: Replace `https://{YOUR_SENTRY_DOMAIN}` with your Sentry address.
 ![Filling out Modal](./images/jira-setup3.png)
 
 8. Click "Install app" (10), now if you select the "Installed Apps" (11) tab next to "Settings", you should see your newly installed app listed under "Sentry" (12). (Note: that "Sentry for Jira" is the SaaS integration).
+
 9. On the right the newly installed app click on the three dots and then click "Manage" (13).
 ![Navigating to App Listing](./images/jira-setup4.png)
 

develop-docs/integrations/jira/index.mdx

@@ -89,6 +89,8 @@ It consists of the following fields:
 
 : **Object, optional**. A dictionary of key-value pairs of arbitrary data attached to the log. Attributes must also declare the type of the value. The following types are supported: `string`, `boolean`, `integer`, `double`. In the future arrays will be supported (`string[]`, `boolean[]`, `integer[]`, `double[]`).
 
+Integers should be a 64-bit signed integer, while doubles should be a 64-bit floating point number. In the future we will support 64-bit unsigned integers.
+
 Example:
 
 ```json
@@ -156,27 +158,6 @@ The SDKs must expose the following configuration options:
 
 - `beforeSendLog`/`before_send_log`: A function that takes a log object and returns a log object. This function is called before sending the log to Sentry. It can be used to modify the log object or to prevent the log from being sent to Sentry. This function is optional.
 
-- `logsSampleRate`/`logs_sample_rate`: A number between 0 and 1 that represents the probability that a log will be sent to Sentry. This sampling decision should be made before a log is processed by SDK to lower performance overhead. Defaults to 1.0.
-
-```js
-Sentry.init({
-  enableLogs: true,
-
-  beforeSendLog(log) {
-    // Prevent logs from being sent to Sentry if the plan type is enterprise
-    if (log.attributes["plan.type"] === "enterprise") {
-      return null;
-    }
-
-    return log;
-  },
-
-  logsSampleRate: 1.0,
-});
-```
-
-At the current moment logs sampling decisions are not propagated to downstream services, or be affected by the `tracesSampleRate` configuration option. In the future there might be more advanced client-side sampling and server-side sampling strategies, but this is not yet defined.
-
 While the logs functionality for an SDK is in an experimental state, SDKs should put these configuration options in an experimental namespace to avoid breaking changes.
 
 ```js
@@ -279,15 +260,14 @@ It's important to note that putting everything immediately on a background threa
 
 The internal SDK implementation is kept purposefully broad as we are still in early stages. As we figure more out about the logs product and payload characteristics, we'll be able to define a more rigorous spec for logging internals in the SDK. SDKs should take care to not expose logging internals as much as possible to userland so that they can be refactored in the future.
 
-### Data Category and Rate Limiting
+In general log processing should follow this order:
 
-A new data category for logs has been added to Relay, `log_item`. Both the `log` envelope and `otel_log` envelope is covered by this data category. This will need to implemented in the SDK. Rate limiting applies as usual, there is no special rate limit or rate limiting behaviour for logs. With this data category, client outcomes should be tracked by the SDKs to track how often logs are dropped by the SDK.
-
-### Buffering
-
-Logs should be buffered before being sent. SDKs should keep a buffer of logs on the client (so you can have logs from multiple traces in the buffer) that flushes out based on some kind of condition. We recommend to use follow the [batch processor specification outlined](/sdk/telemetry/spans/batch-processor/) in the develop docs, but you should choose the approach that works best for your platform. When starting intial development on the SDK you can choose a simple approach to buffer like flushing logs if the buffer length exceeds 25 items, or if 5 seconds have passed.
-
-SDKS should NOT release logging capabilities to users if a buffering implementation has not been added to their SDK when adding logging APIs.
+1. Capture log via [Public APIs](#logger-module) (e.g. `Sentry.logger.info`) or via [SDK integrations](#sdk-integrations).
+1. Check if logging is enabled as per `enableLogs`/`enable_logs` configuration - if not, skip the rest of the steps.
+1. Process captured log (attach attributes as per [default attributes](#default-attributes)).
+1. Run `beforeSendLog`/`before_send_log` to filter or modify the log.
+1. Add log to buffer/batch processor as detailed in [buffering](#buffering).
+1. At time of flushing buffer, send array of logs to Sentry via `log` envelope, apply rate limiting as per [data category and rate limiting](#data-category-and-rate-limiting).
 
 ### Default Attributes
 
@@ -328,6 +308,16 @@ If a log is generated by an SDK integration, the SDK should also set the `sentry
 
 Beyond these attributes, we are exploring if the SDK should also send OS, user, and device information automatically (via reading the appropriate contexts from the scope). Given this behaviour can easily be added as a new feature to the SDK, it does not have to be part of the initial SDK implementation until we make a finalized decision.
 
+### Data Category and Rate Limiting
+
+A new data category for logs has been added to Relay, `log_item`. Both the `log` envelope and `otel_log` envelope is covered by this data category. This will need to implemented in the SDK. Rate limiting applies as usual, there is no special rate limit or rate limiting behaviour for logs. With this data category, client outcomes should be tracked by the SDKs to track how often logs are dropped by the SDK.
+
+### Buffering
+
+Logs should be buffered before being sent. SDKs should keep a buffer of logs on the client (so you can have logs from multiple traces in the buffer) that flushes out based on some kind of condition. We recommend to use follow the [batch processor specification outlined](/sdk/telemetry/spans/batch-processor/) in the develop docs, but you should choose the approach that works best for your platform. When starting intial development on the SDK you can choose a simple approach to buffer like flushing logs if the buffer length exceeds 100 items, or if 5 seconds have passed.
+
+SDKS should NOT release logging capabilities to users if a buffering implementation has not been added to their SDK when adding logging APIs.
+
 ### SDK Integrations
 
 SDKs should aim to have it so that console/logger integrations create logs as per the appropriate log level if `enableLogs`/`enable_logs` is set to true. Examples of this include JavaScript's `console` object and Pythons `logging` standard library.

develop-docs/sdk/telemetry/logs.mdx

@@ -1,5 +1,5 @@
 ---
-title: Set Up Profiling
+title: Set Up Android Profiling
 sidebar_title: Profiling
 description: "Learn how to enable profiling in your app if it is not already set up."
 sidebar_order: 5000

docs/platforms/android/profiling/index.mdx

@@ -133,7 +133,7 @@ SentrySDK.resumeAppHangTracking()
 
 ### App Hangs V2
 
-As of version 8.50.0, you can enable AppHangsV2, which is available on iOS and tvOS. The main difference is that AppHangsV2 differentiates between fully-blocking and non-fully-blocking app hangs, which you might choose to ignore, and since version 8.45.0 measures the duration of app hangs. A fully-blocking app hang is when the main thread is stuck completely, and the app can't render a single frame. A non-fully-blocking app hang is when the app appears stuck to the user, but can still render a few frames. Fully-blocking app hangs are more actionable because the stacktrace shows the exact blocking location on the main thread. Non-fully-blocking app hangs can have a stacktrace that doesn't highlight the exact blocking location, since the main thread isn't completely blocked.
+As of version 8.50.0, you can enable AppHangsV2, which is available on iOS and tvOS. The main difference is that AppHangsV2 differentiates between fully-blocking and non-fully-blocking app hangs, which you might choose to ignore, and measures the duration of app hangs. A fully-blocking app hang is when the main thread is stuck completely, and the app can't render a single frame. A non-fully-blocking app hang is when the app appears stuck to the user, but can still render a few frames. Fully-blocking app hangs are more actionable because the stacktrace shows the exact blocking location on the main thread. Non-fully-blocking app hangs can have a stacktrace that doesn't highlight the exact blocking location, since the main thread isn't completely blocked.
 
 The SDK sets the `exception.type` to `App Hang Fully Blocked` or `App Hang Non Fully Blocked`, so you can filter for App Hangs via `error.type` in Sentry.
 

docs/platforms/apple/common/configuration/app-hangs.mdx

@@ -342,6 +342,14 @@ if (error) {
 }
 ```
 
+<PlatformSection supported={[ "apple.macos"]}>
+
+## Uncaught Exceptions
+
+On macOS, the Sentry Apple SDK can't capture uncaught exceptions out of the box. Please visit <PlatformLink to="/usage/#capturing-uncaught-exceptions">capturing uncaught exceptions</PlatformLink> for more information.
+
+</PlatformSection>
+
 ## Next Steps
 
 - <PlatformLink to="/features">Learn more about Sentry's Apple SDK features</PlatformLink>

docs/platforms/apple/common/index.mdx

@@ -1,5 +1,5 @@
 ---
-title: Set Up Profiling
+title: Set Up Apple Profiling
 sidebar_title: Profiling
 description: "Learn how to enable profiling in your app."
 sidebar_order: 5000

docs/platforms/apple/common/profiling/index.mdx

@@ -1,5 +1,5 @@
 ---
-title: Set Up Profiling
+title: Set Up .NET Profiling
 sidebar_title: Profiling
 description: "Learn how to enable profiling in your app if it is not already set up."
 sidebar_order: 5000