feat: Drop unnecessary default info level for Alert (#12420)

Author: mydea

app/platform-redirect/page.tsx

@@ -79,7 +79,7 @@ export default async function Page(props: {
 
   return (
     <DocPage frontMatter={frontMatter}>
-      <Alert level="info">{platformInfo}</Alert>
+      <Alert>{platformInfo}</Alert>
 
       <ul>
         {platformList.map(p => (

develop-docs/application-architecture/dynamic-sampling/architecture.mdx

@@ -133,7 +133,7 @@ In this case, the matching will happen from **top to bottom** and the following
 1. Rule `1` is matched against the event payload, since it is of type `transaction`. The `samplingValue` is a `factor`, thus the accumulated factors will now be `2.0 * 1.0`, where `1.0` is the identity for the multiplication.
 2. Because rule `1` was a factor rule, the matching continues and rule `2` will be matched against the DSC, since it is of type `trace`. The `samplingValue` is a `sampleRate`, thus the matching will stop and the sample rate will be computed as `2.0 * 0.5 = 1.0`, where `2.0` is the factor accumulated from the previous rule and `0.5` is the sample rate of the current rule.
 
-<Alert title="✨ Note" level="info">
+<Alert title="✨ Note">
 
 It is important to note that a `sampleRate` rule must match in order for a sampling decision to be made; in case this condition is not met, the event will be kept. In practice, each project will have a uniform trace rule which will always match and contain the base sample rate of the organization.
 

develop-docs/application-architecture/dynamic-sampling/fidelity-and-biases.mdx

@@ -5,7 +5,7 @@ sidebar_order: 2
 
 Dynamic Sampling allows Sentry to automatically adjust the amount of data retained based on how valuable the data is to the user. This is technically achieved by applying a **sample rate** to every event, which is determined by a **set of rules** that are evaluated for each event.
 
-<Alert title="✨ Note" level="info">
+<Alert title="✨ Note">
 
 A sample rate is a number in the interval `[0.0, 1.0]` that will determine the likelihood of a transaction to be retained. For example, a sample rate of `0.5` means that the transaction will be retained on average 50% of the time.
 
@@ -21,15 +21,15 @@ There are two available modes to govern the target sample rates for Dynamic Samp
 - **Automatic Mode** dynamically manages the target sample rate for each project based on the target sample rate for the organization, prioritizing lower volume projects to increase visibility. Automatic Mode is active if the organization option `sentry:sampling_mode` is set to `organization`. The target sample rate for the organization is stored in the **organization** option `sentry:target_sample_rate`, and project target sample rates are calculated based on the organization target sample rate.
 - **Manual Mode** allows the user to set static target sample rates on a per-project basis that serve as the baseline sample rate before applying the dynamic biases outlined below. Target sample rates are not adjusted by the system. Manual Mode is active if the organization option `sentry:sampling_mode` is set to `project`. The target sample rates for projects are stored in the **project** option `sentry:target_sample_rate`.
 
-All functionality defaults to Automatic Mode if the option `sentry:sampling_mode` is not set, and all target sample rates default to 1 if the option `sentry:target_sample_rate` is not set. 
+All functionality defaults to Automatic Mode if the option `sentry:sampling_mode` is not set, and all target sample rates default to 1 if the option `sentry:target_sample_rate` is not set.
 
 When the user switches between modes, target sample rates are transferred unless changed explicitly. For example, if the user switches from Automatic Mode to Manual Mode, the sample rates calculated during Automatic Mode are persisted in the project option `sentry:target_sample_rate`. Conversely, if the user switches from Manual Mode to Automatic Mode, the project target sample rates are recalculated based on the overall organization target sample rate.
 
-The [sample rates are periodically recalibrated](https://github.com/getsentry/sentry/blob/9b98be6b97323a78809a829e06dcbef26a16365c/src/sentry/dynamic_sampling/rules/biases/recalibration_bias.py#L11-L44) to ensure that the overall target sample rate is met. This recalibration is done on a project level or organization level, depending on the dynamic sampling mode. Within the target sample rate, Dynamic Sampling **biases towards more meaningful data**. This is achieved by constantly updating and communicating special rules to Relay, via a project configuration, which then applies targeted sampling to every event. 
+The [sample rates are periodically recalibrated](https://github.com/getsentry/sentry/blob/9b98be6b97323a78809a829e06dcbef26a16365c/src/sentry/dynamic_sampling/rules/biases/recalibration_bias.py#L11-L44) to ensure that the overall target sample rate is met. This recalibration is done on a project level or organization level, depending on the dynamic sampling mode. Within the target sample rate, Dynamic Sampling **biases towards more meaningful data**. This is achieved by constantly updating and communicating special rules to Relay, via a project configuration, which then applies targeted sampling to every event.
 
 ![Concept of Fidelity](./images/fidelityAndPriorities.png)
 
-<Alert title="✨ Note" level="info">
+<Alert title="✨ Note">
 For orgs under AM2, Dynamic sampling uses a [sliding window function](https://github.com/getsentry/sentry/blob/cc8cc38c8a108719d068e5622b24a8d0c744e84c/src/sentry/dynamic_sampling/tasks/sliding_window_org.py#L37-L61) over the incoming volume to calculate the target sample rate.
 </Alert>
 
@@ -39,7 +39,7 @@ It is important to note that fidelity only determines an **approximate target sa
 
 Instead, the Sentry backend **computes a set of rules** whose goal is to cooperatively achieve the target sample rate. Determining when and how to set these rules is part of the Dynamic Sampling infrastructure.
 
-<Alert title="✨ Note" level="info">
+<Alert title="✨ Note">
 
 The effectively applied sample rate, in the end, depends on how much data matches each of the bias overrides.
 
@@ -59,7 +59,7 @@ To achieve trace sampling, SDKs pass all fields that can be sampled by [Dynamic
 
 ![Trace Sampling](./images/traceSampling.png)
 
-<Alert title="✨ Note" level="info">
+<Alert title="✨ Note">
 
 In order to achieve full trace sampling, the random number generator used by Relay is seeded with the trace ID inside of the DSC sent by the SDK. This ensures that traces with the same trace ID will always yield the same sampling decision.
 
@@ -115,7 +115,7 @@ The list of development environments is available [here](https://github.com/gets
 For prioritizing dev environments, we use a sample rate of `1.0` (100%), which results in all traces being sampled.
 
 ### Prioritize Low Volume Projects
-<Alert title="✨ Note" level="info">
+<Alert title="✨ Note">
 This bias is only active in Automatic Mode (and not in Manual Mode). It applies to any incoming trace and is defined on a per-project basis.
 </Alert>
 
@@ -126,13 +126,13 @@ The algorithm used in this bias computes a new sample rate with the goal of prio
 ### Prioritize Low Volume Transactions
 This bias is used to prioritize low-volume transactions that can be drowned out by high-volume transactions. The goal is to rebalance sample rates of the individual transactions so that low-volume transactions are more likely to have representative samples. The bias is of type trace, which means that the transaction considered for rebalancing will be the root transaction of the trace.
 
-Prioritization of low volume transactions works slightly differently depending on the dynamic sampling mode: 
-- In **Automatic Mode** (`sentry:sampling_mode` == `organization`), the output of the [boost_low_volume_projects](https://github.com/getsentry/sentry/blob/dee539472e999bf590cfc4e99b9b12981963defb/src/sentry/dynamic_sampling/tasks/boost_low_volume_transactions.py#L183) task is used as the base sample rate for the balancing algorithm. 
+Prioritization of low volume transactions works slightly differently depending on the dynamic sampling mode:
+- In **Automatic Mode** (`sentry:sampling_mode` == `organization`), the output of the [boost_low_volume_projects](https://github.com/getsentry/sentry/blob/dee539472e999bf590cfc4e99b9b12981963defb/src/sentry/dynamic_sampling/tasks/boost_low_volume_transactions.py#L183) task is used as the base sample rate for the balancing algorithm.
 - In **Manual Mode** (`sentry:sampling_mode` == `project`), the project target sample rate is used as the base sample rate for the balancing algorithm.
 
-In order to rebalance transactions, the system retrieves the counts of the transactions for each project and calculates a new sample rate for each transaction. 
+In order to rebalance transactions, the system retrieves the counts of the transactions for each project and calculates a new sample rate for each transaction.
 
-<Alert title="✨ Note" level="info">
+<Alert title="✨ Note">
 
 The algorithms for boosting low volume events are run periodically (with cron jobs) with a sliding window to account for changes in the incoming volume.
 

develop-docs/application-architecture/dynamic-sampling/the-big-picture.mdx

@@ -7,7 +7,7 @@ sidebar_order: 1
 ![Sequencing](./images/sequencing.png)
 
 
-<Alert title="💡 Note" level="info">
+<Alert title="💡 Note">
 
 Dynamic Sampling currently operates on either spans or transactions to measure data throughput. This is controlled by the feature flag `organizations:dynamic-sampling-spans` and usually set to what the organization's subscription is metered by. In development, this currently defaults to transactions.
 The logic between the two data categories is identical, so most of this documentation is kept at a generic level and important differences are pointed out explicitly.
@@ -27,7 +27,7 @@ When events arrive, in a simplified model, they go through the following steps:
 4. **Dynamic Sampling**: based on an internal set of rules, Relay determines a sample rate for every incoming event. A random number generator finally decides whether a payload should be kept or dropped.
 5. **Rate limiting**: events that are sampled by Dynamic Sampling will be stored and indexed. To protect the infrastructure, internal rate limits apply at this point. Under normal operation, this **rate limit is never reached** since dynamic sampling already reduces the volume of events stored.
 
-<Alert title="💡 Example" level="info">
+<Alert title="💡 Example">
 
 A client is sending 1000 events per second to Sentry:
 1. 100 events per second are from old browsers and get dropped through an inbound data filter.
@@ -44,7 +44,7 @@ The ingestion pipeline has two kinds of rate limits that  behave differently com
 1. **High-level request limits on load balancers**: these limits do not differentiate which data is sent by clients and drop requests as soon as the throughput from clients reaches the limit.
 2. **Specific limits per data category in Relay**: these limits apply once requests have been parsed and have gone through basic handling (see [Sequencing](#sequencing) above).
 
-<Alert title="✨️ Note" level="info">
+<Alert title="✨️ Note">
 
 There is a dedicated rate limit for stored events after inbound filters and dynamic sampling. However, it does not affect total events since the fidelity decreases with higher total event volumes and this rate limit is not expected to trigger since Dynamic Sampling already reduces the stored event throughput.
 
@@ -56,7 +56,7 @@ Dynamic sampling ensures complete traces by retaining all events associated with
 
 Despite dynamic sampling providing trace completeness, events or other items (errors, replays, ...) may still be missing from a trace when rate limiting drops one or more of them. Rate limiting drops items without regard for the trace, making each decision independently and potentially resulting in broken traces.
 
-<Alert title="💡 Example" level="info">
+<Alert title="💡 Example">
 
 For example, if there is a trace from `Project A` to `Project B` and `Project B` is subject to rate limiting or quota enforcement, events of `Project B` from the trace initiated by `Project A` are lost.
 
@@ -84,7 +84,7 @@ Each of these metrics can be filtered and grouped by a number of predefined tags
 
 For more granular queries, **stored events are needed**. _The purpose of dynamic sampling here is to ensure that there are always sufficient representative sample events._
 
-<Alert title="💡 Example" level="info">
+<Alert title="💡 Example">
 
 If Sentry applies a 1% dynamic sample rate, you can still receive accurate events per minute (SPM or TPM, depending on event type) and web vital quantiles through total event data backed by metrics. There is also a listing of each of these numbers by the transaction.
 

develop-docs/application-architecture/multi-region-deployment/control-silo.mdx

@@ -15,7 +15,7 @@ Prior to our multi-region offering, all API traffic from customers would be sent
 - DSN host
 - A static list of URL names (region pin list)
 
-<Alert level="info">
+<Alert>
 💡 Requests going to sentry.io do not meet data residency requirements. Customers will need to use region domains in order to not have requests go to the US.
 </Alert>
 

develop-docs/application-architecture/overview.mdx

@@ -100,7 +100,7 @@ In order to offer customers data residency we needed to co-locate the bulk of an
 
 These constraints led our design to having multiple 'silo modes'.
 
-<Alert level="info">
+<Alert>
     ☝ The term ‘silo’ was chosen as other applicable terms (region, zone, partition, cluster) are all taken.
 </Alert>
 

develop-docs/backend/api/design.mdx

@@ -32,7 +32,7 @@ Here are some additional examples:
 - 👍 `/projects/\{organization_slug}/\{project_slug}/issues/`
 - 👎 `/projects/`
 
-<Alert title="Note" level="info">
+<Alert title="Note">
 
 Hierarchy here does not necessarily mean that one collection belongs to a parent collection. For example:
 - `projects/\{project_identifier}/teams/` refers to the **teams** that have been added to specific project
@@ -82,7 +82,7 @@ Here are some notes that can help you decide between similar methods. We use *Ge
 ## Response Object
 Each response object returned from an API should be a serialized version of the Django model associated with the resource. You can see all the existing serializers [here](https://github.com/getsentry/sentry/tree/master/src/sentry/api/serializers/models).
 
- <Alert title="Note" level="info">
+ <Alert title="Note">
 
  Some models might have different serializers based on use case. For example, `Project` can be serialized into `DetailedProjectSerializer` or `ProjectSerializer`. Decide which one to use based on your use case and API scope but **DO NOT RETURN CUSTOM OBJECTS** like \{`slug: project_slug, platform: project_platform`}. We want the API responses to be uniform and useable in multiple automations without adding extra complication to the external developers' code.
 

develop-docs/backend/api/public.mdx

@@ -38,7 +38,7 @@ build. With that being said, there are 3 exceptions where we don't publish APIs:
    that you think it should be published let [owners-api](https://github.com/orgs/getsentry/teams/owners-api)
    know and we can help with that.
 
-<Alert title="Note" level="info">
+<Alert title="Note">
 
 Always keep in mind that your APIs may still be used even if they're `private`. All the APIs
 in the Sentry repo are accessible due to our open-source nature.

develop-docs/backend/application-domains/feature-flags/flagpole.mdx

@@ -183,7 +183,7 @@ features.add(
 feature.<feature_scope>:<feature_name>
 ```
 
-<Alert level="info">
+<Alert>
     The feature config should not be merged until the registration commit in step 1 has been fully deployed to all target environments. This is because Options Automator will fail to push options to any environments missing the option registration.
     If this happens, make sure to rerun the options deployment once all environments have been updated to ensure your feature is active.
 </Alert>

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

@@ -22,7 +22,7 @@ Follow these rules when adding new options:
 
 The value of an option can be any pickleable value.
 
-<Alert level="info">
+<Alert>
   It is safe to declare and use an option in the same pull request, you don't need to
   split them up.
 </Alert>
@@ -55,7 +55,7 @@ from sentry import options
 options.set("performance.some-feature-rate", 0.01)
 ```
 
-<Alert level="info">
+<Alert>
   If you do not have access to the shell, you'll need to contact OPS to set the option
   value for you.
 </Alert>
@@ -125,7 +125,7 @@ from sentry import options
 options.delete("performance.some-feature-rate")
 ```
 
-<Alert level="info">
+<Alert>
   If you do not have access to the shell, you'll need to contact OPS to remove the option
   for you.
 </Alert>