Merge remote-tracking branch 'origin/master' into monitors-alerts-EA

Resolving merge conflict

Author: Shannon Anahata

.github/workflows/algolia-index.yml

@@ -7,6 +7,8 @@ jobs:
   index:
     name: Update Algolia index
     runs-on: ubuntu-latest
+    env:
+      NODE_OPTIONS: '--max-old-space-size=6144'
     steps:
       - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6
 
@@ -28,6 +30,15 @@ jobs:
               - 'platform-includes/**'
             dev-docs:
               - 'develop-docs/**'
+
+      - uses: actions/cache@0057852bfaa89a56745cba8c7296529d2fc39830 # v4
+        with:
+          path: |
+            ${{ github.workspace }}/.next/cache
+          key: nextjs-${{ runner.os }}-${{ steps.setup-node.outputs.node-version }}-${{ hashFiles('**/pnpm-lock.yaml') }}
+          restore-keys: |
+            nextjs-${{ runner.os }}-${{ steps.setup-node.outputs.node-version }}-
+
       - uses: oven-sh/setup-bun@0c5077e51419868618aeaa5fe8019c62421857d6 # v2
         with:
           bun-version: '1.1.34'
@@ -38,7 +49,7 @@ jobs:
       # without introducing another dependency like ts-node or tsx for everyone else
 
       - name: Build index for user docs
-        run: pnpm build && bun ./scripts/algolia.ts
+        run: pnpm enforce-redirects && pnpm generate-og-images && pnpm generate-doctree && pnpm next build && bun ./scripts/algolia.ts
         if: steps.filter.outputs.docs == 'true'
         env:
           ALGOLIA_APP_ID: ${{ secrets.ALGOLIA_APP_ID }}
@@ -50,7 +61,7 @@ jobs:
           NEXT_PUBLIC_SENTRY_DSN: https://examplePublicKey@o0.ingest.sentry.io/0
 
       - name: Build index for developer docs
-        run: pnpm build:developer-docs && bun ./scripts/algolia.ts
+        run: git submodule init && git submodule update && pnpm enforce-redirects && pnpm generate-doctree && NEXT_PUBLIC_DEVELOPER_DOCS=1 pnpm next build && bun ./scripts/algolia.ts
         if: steps.filter.outputs.dev-docs == 'true'
         env:
           ALGOLIA_APP_ID: ${{ secrets.ALGOLIA_APP_ID }}

develop-docs/backend/application-domains/grouping.mdx

@@ -33,11 +33,10 @@ by the client yet, three systems start operating:
    the special `{{ default }}` value.
 
 It's important to know that the grouping algorithm can produce more than one fingerprint hash.  These hashes
-are collected and associated with issues.  There are two types of hashes that can be created:
-
-* flat hashes: these are traditional hashes where all hashes are equal.  If any of these hashes exists in a group
-  it is associated with it and any hash not yet associated with the group is added.
-* hierarchical hashes: these are secondary hashes that can be used to subdivide a group in the grouping tab.
+are collected and associated with issues via the `GroupHash` model.  If any of these hashes exists in a group
+the event is associated with it, and any hash not yet associated with the group is added.  In practice this
+means an event may produce both an "app" hash (using only in-app frames) and a "system" hash (using all frames),
+and either one matching an existing group is sufficient.
 
 # Issue / Group Creation
 
@@ -56,9 +55,40 @@ event as it flows further through the system to make it's way towards snuba, is
 which also means that the group is persisted in snuba along with the event.
 
 Upon group creation, additional code runs such as the triggering of alerts, regression detection and more.
-It is thus relatively expensively to create a group due to the number of additional actions that can be
+It is thus relatively expensive to create a group due to the number of additional actions that can be
 triggered from it.
 
+# AI Grouping
+
+In addition to fingerprint-based grouping, Sentry uses AI to further improve issue grouping accuracy.
+This system identifies issues with similar stacktraces and error messages that might have different fingerprints 
+due to minor code variations. AI grouping works alongside traditional fingerprinting, occurring *after* hash-based lookup
+ and *before* new group creation:
+
+1. The event's hashes are computed via the standard grouping algorithm.
+2. Sentry checks whether any of those hashes already belong to an existing group via the hash-based lookup.
+3. If no existing group is found, and the event is eligible, Sentry generates an embedding
+   of the error's message and in-app stack frames, compares this embedding against existing 
+   error embeddings for that project, and merges the new error into an existing issue if a similar
+   issue is found within the configured threshold.
+4. If no match is found (or the event is ineligible), a new group is created as before.
+
+Eligibility is determined by [`should_call_seer_for_grouping`](https://github.com/getsentry/sentry/blob/master/src/sentry/grouping/ingest/seer.py)
+in `src/sentry/grouping/ingest/seer.py`.  Beyond the fingerprint check above, it also considers:
+
+- Whether the event has a usable stacktrace
+- Whether the event's platform is supported
+- Whether the project has AI-enhanced grouping enabled
+- Rate limits (both global and per-project)
+- A circuit breaker that trips if error rates are too high
+- Stacktrace size limits
+
+Results — including the matched grouphash, match distance, and model version — are
+persisted in the [`GroupHashMetadata`](https://github.com/getsentry/sentry/blob/master/src/sentry/models/grouphashmetadata.py)
+model alongside the event's hash-based grouping metadata.
+
+More details on the AI grouping process can be found on the public facing docs [here](https://docs.sentry.io/concepts/data-management/event-grouping/#ai-enhanced-grouping).
+
 # Merges and Splits
 
 The system does not cope particularly well with merges and splits because the events in Snuba are generally
@@ -148,8 +178,7 @@ existing group.
 Sentry at the moment feeds the entire stack into the group.  There is a way to limit the number of frames
 contributed down to a smaller set by setting a maximum number of frames that should be considered.  This
 has a hypothetical advantage when working with different paths that lead to a bug but have the consequence
-that very large groups can be created.  Creating larger groups is tricker in Sentry as without hierarchical
-grouping there are no good ways to dive into the different stacks in an issue.
+that very large groups can be created.
 
 ## Fallback Grouping
 
@@ -171,37 +200,28 @@ think of grouping as a problem of the source of the error.  At any point the que
 source of the error is "how we call a function" (caller error) or "in the function" (callee error).  Making
 this decision is impossible to make in a general sense, but over time it can be easier to make this call.
 
-Sentry has an experimental grouping system called "hierarchical" grouping where we allow diving into the
-different paths towards a bug by preferring to over-group and then provide a grouping tab that can show
-the different paths by which we came to the error.  However the limitation of this with the current group
-system is that since the group has been created, there is now way to split out, you can end up with a much
-larger group than you desired.
-
 # Paths Forward
 
-The grouping system as implemented relates very close to the work flow that is established with the groups
-that are created.  It is the creator of the groups and as the creator, it drives a big part of the user
-experience that derives from it.  If it were to create a single issue per event, or a single issue for all
-events nothing in Sentry would properly function any more.  It is thus our first point of balancing the
-quality of the workflow.  Unfortunately with the tools available today there we are sitting in a pretty
-tough spot at the time of grouping.  If we get it wrong, the user is likely stuck.
+The grouping system is tightly coupled to the workflow that issues drive.  It is the creator of the groups
+and as the creator, it drives a big part of the user experience.  If it were to create a single issue per
+event, or a single issue for all events, nothing in Sentry would properly function.  It is thus our first
+point of balancing the quality of the workflow.
 
-The following general paths forward are current envisioned:
+## Improving AI-Enhanced Grouping
+
+The introduction of AI-enhanced grouping has already improved the caller-vs-callee problem described
+above, but there is ongoing work to improve model accuracy, expand platform support, and reduce latency.
+Key areas include better handling of hybrid fingerprints, improving confidence thresholds, and training on
+broader datasets.
 
 ## Groups of Groups
 
 The consequences of making too many groups today are alert spam and the inability to work with multiple
 issues at once.  If Sentry were to no longer be alerting on all new groups and tools existed to work
-across multiple groups more opportunities arise.  In particular the grouping algorithm could continue to
+across multiple groups, more opportunities arise.  In particular the grouping algorithm could continue to
 just fingerprint the stack trace but a secondary process could come in periodically and sweep up related
 fingerprints into a larger group.  If we take the `get_current_user` example the creation of 50 independent
-groups is not much of an issue if no alerts are fired.  If after 5 minute the system detected that they are
+groups is not much of an issue if no alerts are fired.  If after 5 minutes the system detected that they are
 in fact all very related (eg: the bug is "in `get_current_user`") it could leave the 50 generated groups
 alone but create a new group that links the other 50 groups, hide/deemphasize the individual 50 groups in
 the UI and let the user work with the larger group instead.
-
-## Evaluate Hierarchical Grouping
-
-We also have the hierarchical grouping prototype which tries to group on fewer inputs.  This system has
-some limitations but it's less likely to create many groups.  Unfortunately the user experience is
-not fleshed out as working with parts of the group is not an option.

develop-docs/development-infrastructure/frontend-development-server.mdx

@@ -12,7 +12,7 @@ You have the ability to only run a frontend development server that will proxy a
 pnpm dev-ui
 ```
 
-The development server can be viewed at [https://dev.getsentry.net:7999](https://dev.getsentry.net:7999). `dev.getsentry.net` is an alias for `localhost` and it's preferred because it supports subdomains. You can also create your own domain alias, as with ngrok, if you like.
+The development server can be viewed at [https://dev.getsentry.net:7999](https://dev.getsentry.net:7999). `dev.getsentry.net` supports subdomains and is the preferred domain for development. It's just an alias of localhost, you can also create your own domain alias, as with ngrok, if you like. If that domain is not resolving then it could be an issue with your DNS settings (or with your home network DNS settings), then add `127.0.0.1 dev.getsentry.net` to your `/etc/hosts` file.
 
 In any case, you can now login to your development server with your Sentry.io credentials. The SSO-login flow will *NOT* work. Only email/password is supported on the login form in development.
 
@@ -21,6 +21,8 @@ While the SSO-login flow will not work, cookies from an existing logged-in sessi
 - [Get Cookie Sync for Chrome](https://chrome.google.com/webstore/detail/sentry-cookie-sync/kchlmkcdfohlmobgojmipoppgpedhijh)
 - [Get Cookie Sync for Firefox](https://addons.mozilla.org/en-US/firefox/addon/sentry-cookie-sync/)
 
+**Note**: If the Cookie Sync extension is not working, make sure to log in to production first (https://sentry.sentry.io), then open the dev server domain in a new tab. (https://sentry.dev.getsentry.net:7999).
+
 ## Admin UI
 
 To access the admin UI (files under `gsAdmin`), you can run:
@@ -39,15 +41,15 @@ Make sure you have cookies synced (see above), as authentication is required to
 
 If you see an error similar to the below when accessing the development server:
 
-![your connection is not private example](../img/connectionNotPrivate.png)
+![your connection is not private example =700x](../img/connectionNotPrivate.png)
 
 You can either grant a temporary exception in your browser, or create and install a local certificate and use your OS to mark them as "trusted". TLS is required for the frontend development service, since the production API is served over https.
 
 Follow the steps [To Enable HTTPS for your devserver](/development/environment/#enabling-https).
 
-You can now run the dev server with `pnpm dev-ui` and open [https://localhost:7999](https://localhost:7999). There should not see a warning about your connection not being private. You should also see a lock or similar icon in the address bar of your browser.
+You can now run the dev server with `pnpm dev-ui` and open [https://dev.getsentry.net:7999](https://dev.getsentry.net:7999). There should not see a warning about your connection not being private. You should also see a lock or similar icon in the address bar of your browser.
 
-![lock icon in address bar](../img/addressBarLockIcon.png)
+![lock icon in address bar =322x](../img/addressBarDevDomain.png)
 
 **NOTE**: For Firefox users that use the master password you will be prompted for it with this message: "Enter Password or Pin for "NSS Certificate DB":"
 

develop-docs/engineering-practices/commit-messages.mdx

@@ -45,7 +45,7 @@ The header has a special format that includes a type, a scope and a subject:
 <footer>
 ```
 
-The **header** is mandatory and the **scope** of the header is optional. If you have a Jira issue to link to, add the **jira-id** the commit belongs to. This helps to connect changes back to Jira tickets.
+The **header** is mandatory and the **scope** of the header is optional. If you have a Linear issue to link to, add the **linear-id** the commit belongs to. This helps to connect changes back to Liner tickets.
 
 Any line of the commit message should not be longer than 100 characters! This allows the message to be easier to read on GitHub as well as in various git tools.