Merge remote-tracking branch 'original/master' into feat/flagsmith-integration

Author: emyller

.babelrc.js.bak

@@ -4,9 +4,6 @@ npm-debug.log*
 yarn-debug.log*
 yarn-error.log*
 
-# Ignore generated export markdown files 
-/public/md-exports/
-
 # Runtime data
 pids
 *.pid
@@ -96,6 +93,8 @@ public/page-data
 # tsbuildinfo file generated by CI
 tsconfig.tsbuildinfo
 
+# Ignore generated files
+/public/md-exports/
 public/mdx-images/*
 
 # yalc

.gitignore

@@ -199,10 +199,10 @@ export async function generateMetadata(props: MetadataProps): Promise<Metadata>
     ? `https://${process.env.VERCEL_URL}`
     : domain;
   let title =
-    'Sentry Docs | Application Performance Monitoring &amp; Error Tracking Software';
+    'Sentry Docs | Application Performance Monitoring & Error Tracking Software';
   let customCanonicalTag: string = '';
   let description =
-    'Self-hosted and cloud-based application performance monitoring &amp; error tracking that helps software teams see clearer, solve quicker, &amp; learn continuously.';
+    'Self-hosted and cloud-based application performance monitoring & error tracking that helps software teams see clearer, solve quicker, and learn continuously.';
   // show og image on the home page only
   const images =
     ((await props.params).path ?? []).length === 0

app/[[...path]]/page.tsx

@@ -5,7 +5,7 @@ import {getDevDocsFrontMatter, getDocsFrontMatter} from 'sentry-docs/mdx';
 
 export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
   if (isDeveloperDocs) {
-    const docs = getDevDocsFrontMatter();
+    const docs = await getDevDocsFrontMatter();
     const baseUrl = 'https://develop.sentry.dev';
     return docsToSitemap(docs, baseUrl);
   }

app/sitemap.ts

@@ -120,43 +120,3 @@ SENTRY_METRICS_OPTIONS = {
 ```
 
 Once configured, the metrics backend will emit to the DogStatsD server and then flushed periodically to Datadog over HTTPS.
-
-## Logging Backend
-
-The `LoggingBackend` reports all operations to the `sentry.metrics` logger. In addition to the metric name and value, log messages also include extra data such as the `instance` and `tags` values which can be displayed using a custom formatter.
-
-```python
-SENTRY_METRICS_BACKEND = 'sentry.metrics.logging.LoggingBackend'
-
-LOGGING['loggers']['sentry.metrics'] = {
-    'level': 'DEBUG',
-    'handlers': ['console:metrics'],
-    'propagate': False,
-}
-
-LOGGING['formatters']['metrics'] = {
-    'format': '[%(levelname)s] %(message)s; instance=%(instance)r; tags=%(tags)r',
-}
-
-LOGGING['handlers']['console:metrics'] = {
-    'level': 'DEBUG',
-    'class': 'logging.StreamHandler',
-    'formatter': 'metrics',
-}
-```
-
-## Composit Experimental Backend
-
-The current implementation of the `MetricsBackend` is known as `CompositExperimentalMetricsBackend`. The `CompositeExperimentalMetricsBackend` reports all operations to both Datadog and Sentry. For this reason, you will be able to see your metrics on both platforms.
-
-```python
-SENTRY_METRICS_BACKEND = "sentry.metrics.composite_experimental.CompositeExperimentalMetricsBackend"
-SENTRY_METRICS_OPTIONS = {
-    "primary_backend": "sentry.metrics.dogstatsd.DogStatsdMetricsBackend",
-    "primary_backend_args": {"statsd_host": "127.0.0.1", "statsd_port": 8126},
-    "allow_list": {
-        # List of metrics sent to Sentry (used for gradual rollout of DDM feature)
-        "my_metric1",
-        "my_metric2",
-}
-```

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

@@ -7,10 +7,9 @@ We use [**Transifex**](https://www.transifex.com/getsentry/sentry) to translate
 
 Other things that mean translating: localization, internationalization, i18n, l10n
 
-If you need access to manage translations, translators, languages, or anything else, please talk to one of the following people:
-
-- Ben Vinegar
-- Vlad Cretu
+<Alert level="info">
+  If you're a sentry employee and need access to manage translations, translators, languages, or anything else, please open a ticket with IT for access to Transifex.
+</Alert>
 
 ## Approving Translators and Languages
 

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

@@ -23,21 +23,3 @@ We use Google Cloud Build to build our Docker containers. Every single commit (i
 ## CI workflow for testing changes with getsentry
 
 See [Workflow](/development/workflow/).
-
-## Troubleshooting CI
-
-You might also be interested in <Link to="/development/environment/#troubleshooting">troubleshooting the dev environment</Link>.
-
----
-
-**Problem:**
-
-When pushing your build to staging and it fails the `Ensure test image` step on Travis.
-
-**Solution:**
-
-You probably forgot to push your branch on Sentry to GitHub.
-
-## Old Systems
-
-For historical reference, we used to use Travis and Percy which have been replaced by GitHub actions and [a GitHub action](https://github.com/getsentry/action-visual-snapshot) respectively.

develop-docs/development-infrastructure/continuous-integration.mdx

@@ -65,12 +65,12 @@ First we will use [mkcert](https://github.com/FiloSottile/mkcert) to create and
 brew install mkcert
 brew install nss # if you use Firefox
 brew install caddy
-yarn mkcert-localhost
+pnpm mkcert-localhost
 ```
 
 Then we will run the reverse proxy as needed:
 ```shell
-yarn https-proxy
+pnpm https-proxy
 ```
 
 After the server is running we can visit the dev server using `https` at port `:8003` instead of over `http` at `:8000`.

develop-docs/development-infrastructure/environment/index.mdx

@@ -155,14 +155,20 @@ crash events to send.
 
 #### Session Replay Integration with Feedback Widgets
 
-When a feedback widget is added to an application and Session Replay's `onErrorSampleRate` is greater than 0, the SDK must sample the replay when the widget **opens**, not when the feedback is submitted. This timing is critical because:
+When Session Replay's `onErrorSampleRate` is greater than 0, SDKs must integrate replay capture with feedback functionality. The timing of replay sampling depends on how feedback is captured:
+
+**Feedback Widget Integration:**
+When a feedback widget is added to an application, the SDK must sample the replay when the widget **opens**, not when the feedback is submitted. This timing is critical because:
 
 - Sampling when the widget opens captures the user's session leading up to the feedback moment
 - Sampling only when feedback is submitted would result in the replay buffer primarily showing the user typing their message, which provides minimal debugging context
 - The replay buffer should contain the user's actions and application state prior to encountering the issue they're reporting
 
 SDKs should trigger replay sampling and flushing as soon as the feedback widget becomes visible to the user, ensuring the complete context is captured regardless of whether the user ultimately submits the feedback.
 
+**Manual API Integration:**
+When feedback is captured using the manual API, the SDK must sample and flush the replay during the execution of the feedback capture API to ensure session context is preserved.
+
 ### Backend Platforms
 
 On backend platforms, SDKs should document how to use the [last event ID](#retrieve-last-event-id) to prompt the user for feedback themselves.

develop-docs/sdk/expected-features/index.mdx

@@ -78,9 +78,9 @@ The *Sample Format V2* is designed for use in continuous profiling. Therefore, a
 
 `client_sdk`
 
-: *Object, optional.* Contains information about the client *SDK*.
+: *Object, required.* Contains information about the client *SDK*.
 
-It can have the following attributes:
+It has the following attributes:
 - `name`
 - `version`
 
@@ -199,8 +199,7 @@ milliseconds.
 : *List, required* Contains a list of sample object captured during execution.
 Each sample can contain the following attributes:
 
-- `timestamp`: *64-bit floating point, required.* Contains the Unix timestamp in seconds with microseconds precision.
-  in seconds with millisecond precision when the sample was captured.
+- `timestamp`: *64-bit floating point, required.* Contains the Unix timestamp in seconds with microseconds precision of when the sample was captured.
 - `stack_id`: *Integer, required.* Contains the stack index from the `stacks` list.
 - `thread_id`: *String, required.* Contains the thread ID on which the sample was captured.