ref(rust): Align docs with core SDK features

docs/platforms/rust/common/configuration/draining.mdx

@@ -4,7 +4,6 @@ sidebar_order: 70
 description: "Learn more about the default behavior of our SDK if the application shuts down unexpectedly."
 ---
 
-The default behavior of most SDKs is to send out events over the network
-asynchronously in the background. This means that some events might be lost if the application shuts down unexpectedly. The SDKs provide mechanisms to cope with this.
+By default the SDK sends out events over the network on a background thread. This means that some events might be lost if the application shuts down unexpectedly. The SDK provides mechanisms to cope with this.
 
 <PlatformContent includePath="configuration/drain-example" />

docs/platforms/rust/common/configuration/filtering.mdx

@@ -16,41 +16,14 @@ Configure your SDK to filter error events by using the <PlatformIdentifier name=
 
 ### Using <PlatformIdentifier name="before-send" />
 
-All Sentry SDKs support the <PlatformIdentifier name="before-send" /> callback method. Because it's called immediately before the event is sent to the server, this is your last chance to decide not to send data or to edit it. <PlatformIdentifier name="before-send" /> receives the event object as a parameter, which you can use to either modify the event’s data or drop it completely by returning `null`, based on custom logic and the data available on the event.
+All Sentry SDKs support the <PlatformIdentifier name="before-send" /> callback method. Because it's called immediately before the event is sent to the server, this is your last chance to decide not to send data or to edit it. <PlatformIdentifier name="before-send" /> receives the event object as a parameter, which you can use to either modify the event’s data or drop it completely by returning `None`, based on custom logic and the data available on the event.
 
 <PlatformContent includePath="configuration/before-send/" />
 
 Note also that breadcrumbs can be filtered, as discussed in [our Breadcrumbs documentation](/product/error-monitoring/breadcrumbs/).
 
-### Using Hints
-
-Hints are available in two places:
-
-1. <PlatformIdentifier name="before-send" /> / <PlatformIdentifier name="before-breadcrumb" />
-2. `eventProcessors`
-
-Event and breadcrumb `hints` are objects containing various information used to put together an event or a breadcrumb. Typically `hints` hold the original exception so that additional data can be extracted or grouping can be affected.
-
-For events, hints contain properties such as `event_id`, `originalException`, `syntheticException` (used internally to generate cleaner stack trace), and any other arbitrary `data` that you attach.
-
-For breadcrumbs, the use of `hints` is implementation dependent. For XHR requests, the hint contains the xhr object itself; for user interactions the hint contains the DOM element and event name and so forth.
-
 <PlatformContent includePath="configuration/before-send-fingerprint">
 
 In this example, the fingerprint is forced to a common value if an exception of a certain type has been caught:
 
 </PlatformContent>
-
-#### Hints for Events
-
-`originalException`
-
-The original exception that caused the Sentry SDK to create the event. This is useful for changing how the Sentry SDK groups events or to extract additional information.
-
-`syntheticException`
-
-When a string or a non-error object is raised, Sentry creates a synthetic exception so you can get a basic stack trace. This exception is stored here for further data extraction.
-
-#### Hints for Breadcrumbs
-
-<PlatformContent includePath="configuration/breadcrumb-hints" />

docs/platforms/rust/common/configuration/options.mdx

@@ -83,20 +83,51 @@ This option can be overridden using `in_app_include`.
 
 </SdkOption>
 
+<SdkOption name="server_name" type='string'>
+
+The server name to be reported. When not set, the server name is not sent with events.
+
+</SdkOption>
+
+<SdkOption name="user_agent" type='string' defaultValue="sentry.rust/<version>">
+
+The user agent that should be reported when sending events to Sentry.
+
+</SdkOption>
+
 <SdkOption name="before_breadcrumb" type='Fn'>
 
-This function is called with an SDK-specific breadcrumb object before the breadcrumb is added to the scope. When `None` is returned from the function, the breadcrumb is dropped. To pass the breadcrumb through, return the first argument, which contains the breadcrumb object.
-The callback typically gets a second argument (called a "hint"), which contains the original object from which the breadcrumb was created to further customize what the breadcrumb should look like.
+This function is called with a breadcrumb struct before the breadcrumb is added to the scope. When `None` is returned from the function, the breadcrumb is dropped. To pass the breadcrumb through, return the breadcrumb itself.
 
 </SdkOption>
 
 <SdkOption name="max_request_body_size" type='MaxRequestBodySize' defaultValue='MaxRequestBodySize::Medium'>
 
-This option controls the maximum size of request bodies that are sent to Sentry.
+This option controls the maximum size of request bodies that are sent to Sentry by HTTP server integrations.
 The default value of `MaxRequestBodySize::Medium` will capture request bodies up to 10kB in size.
 
 </SdkOption>
 
+<SdkOption name="shutdown_timeout" type='Duration' defaultValue="Duration::from_secs(2)">
+
+  The timeout on client drop for draining events on shutdown. This controls how long the SDK will wait for pending events to be sent when shutting down.
+
+</SdkOption>
+
+<SdkOption name="integrations" type="Vec<Arc<dyn Integration>>">
+
+  A list of integrations to enable. This allows you to manually pick and choose the integrations to enable.
+  By default, only the default integrations are enabled.
+
+</SdkOption>
+
+<SdkOption name="default_integrations" type='bool' defaultValue='true'>
+
+  Whether to add default integrations. When set to `false`, no default integrations will be added automatically.
+  The list of default integrations depends on the feature flags of the `sentry` crate that are active.
+
+</SdkOption>
+
 ## Error Monitoring Options
 
 <SdkOption name="sample_rate" type='f32' defaultValue='1.0'>
@@ -107,7 +138,7 @@ The default value of `MaxRequestBodySize::Medium` will capture request bodies up
 
 <SdkOption name="before_send" type='Fn'>
 
-  This function is called with an SDK-specific message or error event object, and can return a modified event object, or `None` to skip reporting the event. This can be used, for instance, for manual PII stripping before sending.
+This function is called with the event payload, and can return a modified event struct, or `None` to skip reporting the event. This can be used, for instance, for manual PII stripping before sending.
 
   By the time `before_send` is executed, all scope data has already been applied to the event. Further modification of the scope won't have any effect.
 
@@ -122,6 +153,12 @@ A number between `0.0` and `1.0`, controlling the percentage chance a given tran
 
 </SdkOption>
 
+<SdkOption name="traces_sampler" type='Fn'>
+
+If given, called with a `SamplingContext` for each transaction to determine the sampling rate. Return a sample rate between `0.0` and `1.0` for the transaction in question. Takes priority over the `traces_sample_rate`.
+
+</SdkOption>
+
 
 ## Transport Options
 
@@ -137,7 +174,48 @@ A number between `0.0` and `1.0`, controlling the percentage chance a given tran
 
 </SdkOption>
 
-<SdkOption name="accept_invalid_certs" type='bool' envVar='SSL_VERIFY'>
+<SdkOption name="accept_invalid_certs" type='bool' envVar='SSL_VERIFY' defaultValue="false">
 Setting this to `true` disables SSL certificate validation when sending outbound requests to Sentry. This should never be enabled when using the SDK in your real codebase or otherwise handling any kind of sensitive or personally identifiable information, as it could be exposed to potential attackers.
 
 </SdkOption>
+
+<SdkOption name="transport" type='Arc<dyn TransportFactory>'>
+
+  The transport to use to send envelopes to Sentry.
+  This is typically either a boxed function taking the client options by reference and returning a `Transport`, a boxed `Arc<Transport>` or alternatively the `DefaultTransportFactory`.
+  By default, the SDK uses a transport based on the `reqwest` crate running on a background thread.
+
+</SdkOption>
+
+## Logging Options
+
+The following features and options are only available when the `logs` feature of the `sentry` crate is enabled. This is not a default feature.
+
+<SdkOption name="enable_logs" type='bool' defaultValue='true'>
+
+Determines whether captured structured logs should be sent to Sentry.
+
+</SdkOption>
+
+<SdkOption name="before_send_log" type='Fn'>
+
+  Callback that is executed for each Log being captured. When `None` is returned from the function, the log record is dropped. To pass the log record through, return the log record itself.
+
+</SdkOption>
+
+
+## Session Tracking Options
+
+The following features and options are only available when the `release-health` feature of the `sentry` crate is enabled. This is a default feature.
+
+<SdkOption name="auto_session_tracking" type='bool' defaultValue='false'>
+
+Enable Release Health Session tracking. When automatic session tracking is enabled, a new "user-mode" session is started at the time of `sentry::init`, and will persist for the application lifetime.
+
+</SdkOption>
+
+<SdkOption name="session_mode" type='SessionMode' defaultValue="SessionMode::Application">
+
+Determine how Sessions are being tracked. Controls the mode for session tracking when `auto_session_tracking` is enabled.
+
+</SdkOption>

docs/platforms/rust/common/configuration/releases.mdx

@@ -13,11 +13,35 @@ A release is a version of your code that is deployed to an <PlatformLink to="/co
 
 <Include name="bind-release-version.mdx" />
 
-## Setting a Release
+## Setup
+
+To use the Release Health features, you need to activate the `release-health` feature flag of the `sentry` crate (enabled by default).
+Additionally, you need to initialize the SDK by specifying additional options:
+
+```rust
+use sentry;
+
+let _guard = sentry::init(("___PUBLIC_DSN___", sentry::ClientOptions {
+    // The `sentry::release_name` macro automatically infers the release from the cargo metadata, and is the preferred way to set the release
+    release: sentry::release_name!(),
+    // OR, manually:
+    // release: Some("my-project-name@2.3.12".into()),
 
-<PlatformContent includePath="set-release" notateUnsupported />
+    // Enables automatic session tracking, according to the configured `session_mode`.
+    // If the value of this option is set `false`, sessions need to be manually managed using `sentry::start_session` and `sentry::stop_session`.
+    auto_session_tracking: true,
 
-How you make the release name (or version) available to your code is up to you. For example, you could use an environment variable that is set during the build process or during initial start-up.
+    // Sets the automatic session tracking mode.
+    // Possible values are `sentry::SessionMode::Application` and `sentry::SessionMode::Request`.
+    // `Application` should be used for user-attended programs, which typically have a single long running session that span the application's lifetime.
+    // `Request` should be used for servers, where each incoming request shall be considered as its own session.
+    session_mode: sentry::SessionMode::Application,
+
+    ..Default::default()
+}));
+```
+
+## Setting a Release
 
 Setting the release name tags each event with that release name. We recommend that you tell Sentry about a new release before sending events with that release name, as this will unlock a few more features. Learn more in our [Releases](/product/releases/) documentation.
 
@@ -33,4 +57,4 @@ In order to monitor release health, the SDK sends session data.
 
 ### Sessions
 
-A session represents the interaction between the user and the application. Sessions contain a timestamp, a status (if the session was OK or if it crashed), and are always linked to a release. Most Sentry SDKs can manage sessions automatically.
+A session represents the interaction between the user and the application. Sessions contain a timestamp, a status (if the session was OK or if it crashed), and are always linked to a release.

docs/platforms/rust/common/data-management/sensitive-data/index.mdx

@@ -19,21 +19,19 @@ These are some great examples for data scrubbing that every company should think
 
 We offer the following options depending on your legal and operational needs:
 
-- filtering or scrubbing sensitive data within the SDK, so that data is _not sent to_ Sentry. Different SDKs have different capabilities, and configuration changes require a redeployment of your application.
+- filtering or scrubbing sensitive data within the SDK, so that data is _not sent to_ Sentry. Configuration changes require a redeployment of your application.
 - [configuring server-side scrubbing](/security-legal-pii/scrubbing/server-side-scrubbing/) to ensure Sentry does _not store_ data. Configuration changes are done in the Sentry UI and apply immediately for new events.
 - [running a local Relay](/product/relay/) on your own server between the SDK and Sentry, so that data is _not sent to_ Sentry while configuration can still be applied without deploying.
 
 <Alert>
 
 Ensure that your team is aware of your company's policy around what can and cannot be sent to Sentry. We recommend determining this policy early in your implementation and communicating it as well as enforcing it via code review.
 
-If you are using Sentry in your mobile app, read our [frequently asked questions about mobile data privacy](/security-legal-pii/security/mobile-privacy/) to assist with Apple App Store and Google Play app privacy details.
-
 </Alert>
 
 ## Personally Identifiable Information (PII)
 
-Our newer SDKs do not purposefully send PII to stay on the safe side. This behavior is controlled by an option called [`send-default-pii`](../../configuration/options/#send-default-pii).
+The SDK purposefully does not send PII to stay on the safe side. This behavior is controlled by an option called [`send-default-pii`](../../configuration/options/#send-default-pii).
 
 Turning this option on is required for certain features in Sentry to work, but also means you will need to be even more careful about what data is being sent to Sentry (using the options below).
 
@@ -43,14 +41,13 @@ If you _do not_ wish to use the default PII behavior, you can also choose to ide
 
 ### <PlatformIdentifier name="before-send" /> & <PlatformIdentifier name="before-send-transaction" />
 
-SDKs provide a <PlatformIdentifier name="before-send" /> hook, which is invoked before an error or message event is sent and can be used to modify event data to remove sensitive information. Some SDKs also provide a <PlatformIdentifier name="before-send-transaction" /> hook which does the same thing for transactions. We recommend using <PlatformIdentifier name="before-send" /> and <PlatformIdentifier name="before-send-transaction" /> in the SDKs to **scrub any data before it is sent**, to ensure that sensitive data never leaves the local environment.
+The SDK provides a <PlatformIdentifier name="before-send" /> hook, which is invoked before an error or message event is sent and can be used to modify event data to remove sensitive information. We recommend using <PlatformIdentifier name="before-send" /> in the SDK to **scrub any data before it is sent**, to ensure that sensitive data never leaves the local environment.
 
 <PlatformContent includePath="configuration/before-send/" />
 
 Sensitive data may appear in the following areas:
 
-- Stack-locals → Some SDKs (Python, PHP and Node) will pick up variable values within the stack trace. These can be scrubbed, or this behavior can be disabled altogether if necessary.
-- Breadcrumbs → Some SDKs (JavaScript and the Java logging integrations, for example) will pick up previously executed log statements. **Do not log PII** if using this feature and including log statements as breadcrumbs in the event. Some backend SDKs will also record database queries, which may need to be scrubbed. Most SDKs will add the HTTP query string and fragment as a data attribute to the breadcrumb, which may need to be scrubbed.
+- Breadcrumbs → The SDK can create breadcrumbs out of log events/records when using the `tracing` and `log` integrations. **Do not log PII** if using this feature and including log statements as breadcrumbs in the event.
 - User context → Automated behavior is controlled via <PlatformIdentifier name="send-default-pii" />.
 - HTTP context → Query strings may be picked up in some frameworks as part of the HTTP request context.
 - Transaction Names → In certain situations, transaction names might contain sensitive data. For example, a browser's pageload transaction might have a raw URL like `/users/1234/details` as its name (where `1234` is a user id, which may be considered PII). In most cases, our SDKs can parameterize URLs and routes successfully, that is, turn `/users/1234/details` into `/users/:userid/details`. However, depending on the framework, your routing configuration, race conditions, and a few other factors, the SDKs might not be able to completely parameterize all of your URLs.
@@ -82,4 +79,4 @@ As a best practice you should always avoid logging confidential information. If
 
 - Anonymize the confidential information within the log statements (for example, swap out email addresses -> for internal identifiers)
 - Use <PlatformIdentifier name="before-breadcrumb" /> to filter it out from breadcrumbs before it is attached
-- Disable logging breadcrumb integration (for example, as described [here](/platforms/javascript/configuration/integrations/breadcrumbs/))
+- Disable the integration that's creating breadcrumbs out of the logs

docs/platforms/rust/common/enriching-events/breadcrumbs/index.mdx

@@ -23,4 +23,4 @@ Manually record a breadcrumb:
 
 ## Automatic Breadcrumbs
 
-<PlatformContent includePath="enriching-events/breadcrumbs/automatic-breadcrumbs" />
+Breadcrumbs are recorded automatically out of `TRACE` and `DEBUG` level events/records when using the integrations for the `tracing` and `log` crates respectively.

docs/platforms/rust/common/enriching-events/context/index.mdx

@@ -29,7 +29,7 @@ Learn more about conventions for common contexts in the [contexts interface deve
 
 When sending context, _consider payload size limits_. Sentry does not recommend sending the entire application state and large data blobs in contexts. If you exceed the maximum payload size, Sentry will respond with HTTP error `413 Payload Too Large` and reject the event.
 
-The Sentry SDK will try its best to accommodate the data you send and trim large context payloads. Some SDKs can truncate parts of the event; for more details, see the [developer documentation on SDK data handling](https://develop.sentry.dev/sdk/expected-features/data-handling/).
+The Sentry SDK will try its best to accommodate the data you send and trim large context payloads. The SDK can truncate parts of the event; for more details, see the [developer documentation on SDK data handling](https://develop.sentry.dev/sdk/expected-features/data-handling/).
 
 ## Additional Data