feat (native): update transport proxy docs

.env.example

@@ -4,4 +4,4 @@
 # be careful not to expose sensitive data (in this case your Algolia admin key)
 
 NEXT_PUBLIC_ALGOLIA_APP_ID=OOK48W9UCL
-NEXT_PUBLIC_ALGOLIA_SEARCH_KEY=ca98597f559459c216891b75989832f8
+NEXT_PUBLIC_ALGOLIA_SEARCH_KEY=ca98597f559459c216891b75989832f8  #trufflehog:ignore

develop-docs/sdk/overview.mdx

@@ -262,6 +262,7 @@ and Sentry:
 - `deflate`: Using [zlib](http://tools.ietf.org/html/rfc1950) structure with the
   [deflate](http://tools.ietf.org/html/rfc1951) compression algorithm.
 - `br`: Using the [Brotli](https://en.wikipedia.org/wiki/Brotli) algorithm.
+- `zstd`: Using the [zstd](https://datatracker.ietf.org/doc/html/rfc8878) algorithm.
 
 ## Transfer Encoding
 

docs/platforms/dotnet/common/enriching-events/scopes/index.mdx

@@ -34,24 +34,7 @@ other hand are more user facing. You can call <PlatformIdentifier name="configur
 time to modify data stored on the scope. This is useful for doing things like
 [modifying the context](../context/).
 
-<Alert>
-
-If you are very curious about how thread locality works for scope data, in .NET there
-are two modes for managing "ambient data". Usuaully Sentry will automatically choose the
-most appropriate mode for your application type. However this can be overridden by
-setting [`SentryOptions.IsGlobalModeEnabled`](../../configuration/options/#is-global-mode-enabled) manually.
-
-If global mode is disabled (appropriate for most server based applications), the
-ambient scope data is stored as an `AsyncLocal` and so it will flow with the execution
-context. Stephen Toub's blog post on [ExecutionContext vs SynchronizationContext](https://devblogs.microsoft.com/pfxteam/executioncontext-vs-synchronizationcontext/)
-explains that concept in more detail.
-
-If global mode is enabled (appropriate for desktop applications), ambient scope data is
-stored as a Singleton and available globally. This means you can set context (such as
-the user logged into the application) once and it will be sent with all events, regardless
-of whether the event was captured on the UI thread or a background thread.
-
-</Alert>
+<Include name="platforms/configuration/options/thread-locality.mdx" />
 
 When you call a global function such as <PlatformIdentifier name="capture-event" /> internally Sentry
 discovers the current hub and asks it to capture an event. Internally the hub will

docs/platforms/native/configuration/transports.mdx

@@ -49,14 +49,31 @@ The transport is invoked in the same thread as the call to
 `sentry_capture_event`. Consider to offload network communication to a
 background thread or thread pool to avoid blocking execution.
 
-## Using an HTTP Proxy
+## Using a Proxy
 
-The Native SDK allows the configuration of an HTTP proxy through which requests can be tunneled to our backend. This proxy must allow `CONNECT` requests to establish a proxy connection. It can be configured via the following option interface:
+The Native SDK allows the configuration of an `HTTP` (`CONNECT`) or `SOCKS5` proxy through which requests can be tunneled to our backend. It can be configured via the following option interface:
 
 ```c
 sentry_options_t *options = sentry_options_new();
-sentry_options_set_http_proxy(options, "http://my.proxy:10010");
+sentry_options_set_proxy(options, "http://my.proxy:8080");
 sentry_init(options);
 
 /* ... */
 ```
+The same function can also be used for the `SOCKS5` proxy:
+```c
+sentry_options_t *options = sentry_options_new();
+sentry_options_set_proxy(options, "socks5://my.proxy:1080");
+sentry_init(options);
+
+/* ... */
+```
+
+
+We support `HTTP` proxies on all platforms, and `SOCKS5` proxies on Linux and macOS. Depending on the platform, the transport provides a fallback in case the proxy is not reachabled. The following table shows the expected behaviour.
+
+| Platform | http-proxy                                          | socks-proxy                                          |
+|----------|-----------------------------------------------------|------------------------------------------------------|
+| Windows  | Internal: fallback <br /> Crashpad: fallback        | N/A                                                  |
+| Linux    | Internal: fallback <br />  Crashpad: fallback       | Internal: no fallback <br />  Crashpad: no fallback  |
+| macOS    | Internal: no fallback <br />  Crashpad: no fallback | Internal: no fallback <br />  Crashpad: fallback     |

docs/platforms/powershell/enriching-events/scopes/index.mdx

@@ -34,24 +34,7 @@ other hand are more user facing. You can call <PlatformIdentifier name="configur
 time to modify data stored on the scope. This is useful for doing things like
 [modifying the context](../context/).
 
-<Alert>
-
-If you are very curious about how thread locality works for scope data, in .NET there
-are two modes for managing "ambient data". Usuaully Sentry will automatically choose the
-most appropriate mode for your application type. However this can be overridden by
-setting [`SentryOptions.IsGlobalModeEnabled`](../../configuration/options/#is-global-mode-enabled) manually.
-
-If global mode is disabled (appropriate for most server based applications), the
-ambient scope data is stored as an `AsyncLocal` and so it will flow with the execution
-context. Stephen Toub's blog post on [ExecutionContext vs SynchronizationContext](https://devblogs.microsoft.com/pfxteam/executioncontext-vs-synchronizationcontext/)
-explains that concept in more detail.
-
-If global mode is enabled (appropriate for desktop applications), ambient scope data is
-stored as a Singleton and available globally. This means you can set context (such as
-the user logged into the application) once and it will be sent with all events, regardless
-of whether the event was captured on the UI thread or a background thread.
-
-</Alert>
+<Include name="platforms/configuration/options/thread-locality.mdx" />
 
 When you call a global function such as <PlatformIdentifier name="capture-event" /> internally Sentry
 discovers the current hub and asks it to capture an event. Internally the hub will

docs/platforms/python/integrations/index.mdx

@@ -116,6 +116,7 @@ The Sentry SDK uses integrations to hook into the functionality of popular libra
 | <LinkWithPlatformIcon platform="python.asyncio"       label="asyncio"         url="/platforms/python/integrations/asyncio" />       |                  |
 | <LinkWithPlatformIcon platform="python.pure_eval"     label="Enhanced Locals" url="/platforms/python/integrations/pure_eval" />     |                  |
 | <LinkWithPlatformIcon platform="python.gnu_backtrace" label="GNU Backtrace"   url="/platforms/python/integrations/gnu_backtrace" /> |                  |
+| <LinkWithPlatformIcon platform="python.rust_tracing"                 label="Rust Tracing"    url="/platforms/python/integrations/rust_tracing" />  |                  |
 | <LinkWithPlatformIcon platform="python.socket"        label="Socket"          url="/platforms/python/integrations/socket" />        |                  |
 | <LinkWithPlatformIcon platform="python.sys_exit"      label="sys.exit"        url="/platforms/python/integrations/sys_exit" />      |                  |
 | <LinkWithPlatformIcon platform="python.tryton"        label="Tryton"          url="/platforms/python/integrations/tryton" />        |                  |

docs/platforms/python/integrations/rust_tracing/index.mdx

@@ -0,0 +1,187 @@
+---
+title: Rust Tracing
+description: "Learn about the Rust Tracing integration and how to get performance data for Rust native extensions."
+---
+
+`RustTracingIntegration` acts as a bridge between the Sentry Python SDK and Rust's [`tracing` framework](https://tracing.rs/). With this integration, traces that begin in Python can extend into Rust seamlessly.
+
+<Alert level="warning">
+
+This integration assumes that your Rust native extension runs synchronously on the current thread. Emitting tracing data from other threads or Rust code that uses `async`/`.await` may corrupt the current trace.
+
+</Alert>
+
+## Install
+
+`RustTracingIntegration` requires setup in both Python and Rust to work.
+
+### Rust
+In your Rust native extension, you'll need three crates as dependencies in `Cargo.toml`:
+- [`tracing-subscriber`](https://crates.io/crates/tracing_subscriber)
+- [`pyo3`](https://crates.io/crates/pyo3)
+- [`pyo3-python-tracing-subscriber`](https://crates.io/crates/pyo3_python_tracing_subscriber)
+
+### Python
+In your Python project, you'll need to install the Sentry SDK from PyPI.
+```bash
+pip install --upgrade sentry-sdk
+```
+
+## Configure
+
+As with installing, configuring `RustTracingIntegration` requires some work in both Python and Rust.
+
+### Rust
+
+In your Rust native extension, you need to expose a way for `RustTracingIntegration` to subscribe to `tracing` updates. A simple setup may look like this:
+```rust
+#[pyfunction]
+pub fn initialize_tracing(py_impl: Bound<'_, PyAny>) {
+    tracing_subscriber::registry()
+        .with(pyo3_python_tracing_subscriber::PythonCallbackLayerBridge::new(py_impl))
+        .init();
+}
+
+#[pymodule]
+fn my_rust_extension(m: &Bound<'_, PyModule>) -> PyResult<()> {
+    m.add_function(wrap_pyfunction!(initialize_tracing, m)?)?;
+
+    Ok(())
+}
+```
+
+### Python
+
+Create an instance of `RustTracingIntegration` and add it to your list of integrations when initializing the Sentry SDK.
+
+<OnboardingOptionButtons
+  options={[
+    'error-monitoring',
+    'performance',
+    'profiling',
+  ]}
+/>
+
+```python {filename:main.py} {"onboardingOptions": {"performance": "9-11", "profiling": "12-15"}}
+import sentry_sdk
+from sentry_sdk.integrations.rust_tracing import RustTracingIntegration
+
+import my_rust_extension
+
+async def main():
+    sentry_sdk.init(
+        dsn="___PUBLIC_DSN___",
+        # Set traces_sample_rate to 1.0 to capture 100%
+        # of transactions for tracing.
+        traces_sample_rate=1.0,
+        # Set profiles_sample_rate to 1.0 to profile 100%
+        # of sampled transactions.
+        # We recommend adjusting this value in production.
+        profiles_sample_rate=1.0,
+        integrations=[
+            RustTracingIntegration(
+                "my_rust_extension",
+                my_rust_extension.initialize_tracing,
+                include_tracing_fields=True,
+            ),
+        ],
+    )
+
+    # your code goes here.
+    ...
+
+asyncio.run(main())
+```
+
+
+## Verify
+
+A simple way to check if the integration is hooked up correctly is to set a custom `event_type_mapping` and `span_filter` that prints or logs `tracing` event metadata and then call a Python function that uses your Rust native extension.
+```python
+from sentry_sdk.integrations.rust_tracing import (
+    default_event_type_mapping,
+    default_span_filter,
+    EventTypeMapping,
+    RustTracingIntegration,
+)
+
+import my_rust_extension
+
+def custom_event_type_mapping(metadata: dict) -> EventTypeMapping:
+    print(metadata)
+    return default_event_type_mapping(metadata)
+
+def custom_span_filter(metadata: dict) -> bool:
+    print(metadata)
+    return default_span_filter(metadata)
+
+sentry_sdk.init(
+    # ...
+    integrations=[
+        RustTracingIntegration(
+            "my_rust_extension",
+            my_rust_extension.initialize_tracing,
+            event_type_mapping=custom_event_type_mapping,
+            span_filter=custom_span_filter,
+        ),
+    ],
+)
+```
+
+To see the results on [sentry.io](https://sentry.io), go to the Traces section for your project and search for a Python span that calls a function from your Rust native extension. If the integration is working and the Rust function is instrumented with the Rust `tracing` framework, then the Python span will have a Rust child, and the Rust child may have a whole tree of Rust spans beneath it.
+
+The `pyo3-python-tracing-subscriber` crate has [a working example of a Sentry integration](https://github.com/getsentry/pyo3-python-tracing-subscriber/tree/main/demo).
+
+## Options
+
+`RustTracingIntegration` accepts a few arguments:
+- `identifier` (required)
+
+  A unique identifier for this native extension. If your project uses more than one Rust native extension, each of them needs its own `RustTracingIntegration`.
+
+- `initializer` (required)
+
+  A function from your native extension that `RustTracingIntegration` can call to subscribe to `tracing` events.
+
+  See the `initialize_tracing` example in [the _Configure_ section above](#configure)
+
+- `event_type_mapping` (optional)
+
+  A function that decides what type of Sentry event to create for a given `tracing` event.
+
+  It takes a single argument: a dictionary containing data from [`tracing::Metadata`](https://docs.rs/tracing/latest/tracing/struct.Metadata.html).
+
+  It returns a `sentry_sdk.integrations.rust_tracing.EventTypeMapping`.
+
+  Uses `sentry_sdk.integrations.rust_tracing.default_event_type_mapping` by default.
+
+- `span_filter` (optional)
+
+  A function that decides whether to drop a given `tracing` span.
+
+  It takes a single argument: a dictionary containing data from [`tracing::Metadata`](https://docs.rs/tracing/latest/tracing/struct.Metadata.html).
+
+  It returns `True` if a span should be processed and `False` if it should be dropped.
+
+  Uses `sentry_sdk.integrations.rust_tracing.default_span_filter` by default.
+
+- `include_tracing_fields` (optional)
+
+  A boolean controlling whether the values of a `tracing` span's key-value fields will be attached to the corresponding Sentry span.
+
+  If it is `None`, this behavior will be controlled by <PlatformLink to="/configuration/options/#send-default-pii">the `send_default_pii` option</PlatformLink> set during SDK initialization. If it is `False`, field values will be redacted on Sentry spans. If it is `True`, field values will be included on Sentry spans.
+
+  The default value of this option is `None`.
+
+  <Alert level="warning">
+
+  When the `tracing::instrument` attribute is applied to a Rust function, `tracing` will set all of the function's arguments as span fields by default. This behavior can cause a function argument that contains sensitive data to unintentionally be sent to Sentry. To avoid that, `include_tracing_fields` by default will defer to the <PlatformLink to="/configuration/options/#send-default-pii">`send_default_pii`</PlatformLink> option which can be set during SDK initialization.
+
+  If you want to set `include_tracing_fields` or <PlatformLink to="/configuration/options/#send-default-pii">`send_default_pii`</PlatformLink> to `True`, see our documentation for <PlatformLink to="/data-management/sensitive-data/">managing sensitive data</PlatformLink> for ways to keep sensitive data from leaking.
+
+  </Alert>
+
+## Supported Versions
+
+- Python: 3.7+
+- Rust: 1.63+

docs/platforms/unity/enriching-events/scopes/index.mdx

@@ -34,24 +34,7 @@ other hand are more user facing. You can call <PlatformIdentifier name="configur
 time to modify data stored on the scope. This is useful for doing things like
 [modifying the context](../context/).
 
-<Alert>
-
-If you are very curious about how thread locality works for scope data, in .NET there
-are two modes for managing "ambient data". Usuaully Sentry will automatically choose the
-most appropriate mode for your application type. However this can be overridden by
-setting [`SentryOptions.IsGlobalModeEnabled`](../../configuration/options/#is-global-mode-enabled) manually.
-
-If global mode is disabled (appropriate for most server based applications), the
-ambient scope data is stored as an `AsyncLocal` and so it will flow with the execution
-context. Stephen Toub's blog post on [ExecutionContext vs SynchronizationContext](https://devblogs.microsoft.com/pfxteam/executioncontext-vs-synchronizationcontext/)
-explains that concept in more detail.
-
-If global mode is enabled (appropriate for desktop applications), ambient scope data is
-stored as a Singleton and available globally. This means you can set context (such as
-the user logged into the application) once and it will be sent with all events, regardless
-of whether the event was captured on the UI thread or a background thread.
-
-</Alert>
+<Include name="platforms/configuration/options/thread-locality.mdx" />
 
 When you call a global function such as <PlatformIdentifier name="capture-event" /> internally Sentry
 discovers the current hub and asks it to capture an event. Internally the hub will

docs/product/issues/issue-details/replay-issues/hydration-error.mdx

@@ -19,25 +19,35 @@ Hydration errors represent a mismatch between the server-rendered HTML, and the
 
 Generally, the visual tools are a good place to start to identify the issue, but keep in mind that sometimes differences can appear below the fold, or there can be differences in hidden DOM nodes or attributes, so inspecting the HTML is important too.
 
-### Example Error
+#### Example Error
 
 In the example below we'll look at a hydration error and see how each tool helps to debug the problem.
 
 The problem is that code highlighting is not applied on the server. When the server renders the PHP code block in the bottom-center of the page, all the code has a white font color. After hydration syntax highlighting is applied, the code snippet is colorful.
 
-#### Image Slider Tool
+### Image Slider
 
 The image slider tool allows for comparing the two page states by overlaying the images on top of each other. Click and drag the purple line to reveal one image or the other.
 
 ![image slider tool](./img/hydration-error-image-slider-tool.png)
 
-#### Side-by-Side Image Tool
+### Side-by-Side Image
 
 View images side-by-side to see large chunks of the page that may differ.
 
 ![side by side image tool](./img/hydration-error-side-by-side-image-tool.png)
 
-#### HTML Diff Tool
+### Tree Compare
+
+Use the tree compare tool to list specifically which DOM nodes were added, removed, or had attributes changed.
+
+You can see each change to the page, and when it happened within the context of the hydration error. In this case one mutation happened at the timestamp `1732089574790` which was at time offset `1790`, or 1.7 seconds since the start of the captured replay. Within this mutation 39 nodes were added, 2 nodes had some attributes changed, and 4 nodes were removed.
+
+We show a CSS selector for each node in the tree to make it easier to identify the component that was changed. Note that some changed nodes might exist outside your React render tree and won't cause hydration errors.
+
+![tree compare tool](./img/hydration-error-tree-compare-tool.png)
+
+### HTML Diff
 
 The HTML diff tool is a basic HTML comparison. It is useful if the hydration error is caused by hidden DOM nodes, different attributes on a DOM node, or there's mismatched content below the fold.
 

includes/feature-limited-on-team-retention.mdx

@@ -1,5 +1,5 @@
 <Note>
 
-This view is only available on Team and Business plans. On Team plans, you won't be able to query data that's more than 7 days old. To enable querying for all your data, upgrade to the <a href="https://sentry.io/pricing/" target="_blank">Business or Enterprise plan</a>.
+This view is only available on Team and Business plans. Team plans can access the last 7 days of data, while Business plans can access the last 90 days. To enable extended data access, upgrade to the <a href="https://sentry.io/pricing/" target="_blank">Business or Enterprise plan</a>.
 
 </Note>