downrank API search results

.github/workflows/test.yml

@@ -62,7 +62,10 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/[email protected]
-      - uses: getsentry/action-setup-volta@c52be2ea13cfdc084edb806e81958c13e445941e # v1.2.0
+      - name: Set up Node
+        uses: actions/setup-node@v4
+        with:
+          node-version-file: 'package.json'
       - uses: actions/cache@v4
         id: cache
         with:

develop-docs/sdk/expected-features/data-handling.mdx

@@ -111,6 +111,8 @@ Fields in the event payload that allow user-specified or dynamic values are rest
 
 - Mappings of values (such as HTTP data, extra data, etc) are limited to 50 item pairs.
 - Event IDs are limited to 36 characters and must be valid UUIDs.
+- Flag keys are limited to 32 characters.
+- Flag values are limited to 200 characters.
 - Tag keys are limited to 32 characters.
 - Tag values are limited to 200 characters.
 - Culprits are limited to 200 characters.

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

@@ -30,7 +30,7 @@ What scope means depends on the application, for a web framework it is most like
 
 ## Automatic Context Data
 
-Automatic addition of useful attributes such as `tags` or `extra` or specific `contexts`. Typically means the SDK hooks into a framework so that it can set attributes that are known to be useful for most users. Please check [Data Handling](/sdk/expected-features/data-handling) for considerations.
+Automatic addition of useful attributes such as `flags` or `tags` or `extra` or specific `contexts`. Typically means the SDK hooks into a framework so that it can set attributes that are known to be useful for most users. Please check [Data Handling](/sdk/expected-features/data-handling) for considerations.
 
 ## Breadcrumbs
 
@@ -118,24 +118,15 @@ This functionality should be gated behind the `includeLocalVariables` option, wh
 
 ## Feature Flags
 
-An SDK may expose a Scope property for tracking feature flag evaluations. When the scope forks, it's important to clone the feature flags property. Leaking flag evaluations between threads could lead to inaccurate feature flag evaluation logs.
+An SDK may optionally support feature flag collection. Feature flags are collected on evaluation, stored on the scope, and submitted to Sentry on error obeying the schema specified in the <Link to="/sdk/data-model/event-payloads/contexts/#feature-flag-context">Feature Flag Context</Link> protocol documentation.
 
-The Scope's flag property should have a capped capacity and should prefer recently-evaluated flags over less-recently-evaluated flags. The recommended data structure is a LRU-cache but it is not required so long as the data structure behaves similarly. Serious deviations from the behavior of an LRU-cache should be documented for your language.
+If an SDK supports feature flags it must expose a function `set_flag` which has identical behavior to the `set_tag` function. It must accept a key of type string and a value which is a union of string, boolean, integer, float, and structure. An SDK may hold up to 100 evaluations. Evaluations are ordered based on their evaluation time. Typically, an LRU cache is used to store feature flags. When the capacity of the cache is exceeded the oldest flag is dropped. Any (or multiple) data structure(s) may be chosen by the SDK to store feature flags as long as the evaluation order of the flags is maintained.
 
-The Scope's flag property should expose two methods: `get/0` and `set/2`. `set/2` takes two arguments. The first argument is the name of the flag. It is of type string. The second argument is the evaluation result. It is of type boolean. `set/2` should remove all entries from the LRU-cache which match the provided flag's name and append the new evaluation result to the end of the queue. `get/0` accepts zero arguments. The `get/0` method must return a list of serialized flag evaluation results in order of evaluation. Oldest values first, newest values last. See the <Link to="/sdk/data-model/event-payloads/contexts/#feature-flag-context">Feature Flag Context</Link> protocol documentation for details.
+Because flags are stored on the scope, when a scope forks the flags data structure must be cloned. Failure to clone the data structure appropriately will lead to flags leaking across thread boundaries and lead to unexpected results.
 
 ### Integrations
 
-Integrations automate the work of tracking feature flag evaluations and serializing them on error context. An integration should hook into third-party SDK and record feature flag evaluations using the current scope. For example, in Python an integration would call `sentry_sdk.get_current_scope().flags.set(...)` on each flag evaluation.
-
-An integration is also responsible for registering an "on error" hook with the Sentry SDK. When an error occurs the integration should request the current scope and serialize the flags property. For example, in Python an integration might define this callback function:
-
-```python
-def flag_error_processor(event, exc_info):
-    scope = sentry_sdk.get_current_scope()
-    event["contexts"]["flags"] = {"values": scope.flags.get()}
-    return event
-```
+Integrations automate the work of tracking feature flag evaluations. An integration should hook into a third-party SDK and record feature flag evaluations using the current scope.
 
 ## Desymbolication
 

develop-docs/sdk/miscellaneous/hub_and_scope_refactoring.mdx

@@ -78,7 +78,7 @@ This scope is probably only used for process-wide data like the `release`.
 
 **Isolation Scope**
 
-This scope holds data only applicable to the current request (on a server), tab (in a browser), or user (on a mobile). The top-level APIs that manipulate data (like `sentry_sdk.set_tag()`, `sentry_sdk.set_context()` etc) write to the isolation scope (at least once the migration phase is over, see "Backwards Compatibility").
+This scope holds data only applicable to the current request (on a server), tab (in a browser), or user (on a mobile). The top-level APIs that manipulate data (like `sentry_sdk.set_flag()`, `sentry_sdk.set_tag()`, `sentry_sdk.set_context()` etc.) write to the isolation scope (at least once the migration phase is over, see "Backwards Compatibility").
 
 The isolation scope is stored in a context variable, thread local, async local, or something similar (depending on the platform). It may also be stored on OTel `Context` so we can rely on OTels `Context` propagation once SDKs implement POTEL.
 

develop-docs/sdk/miscellaneous/unified-api/index.mdx

@@ -216,6 +216,8 @@ Sentry.configureScope((scope) =>
 
 - `scope.set_extras(extras)`: Sets an object with key/value pairs, convenience function instead of multiple `set_extra` calls. As with `set_extra` this is considered deprecated functionality.
 
+- `scope.set_flag(key, value)`: Sets the flag to a string value, overwriting a potential previous value. Entries can not be removed except by expiration.
+
 - `scope.set_tag(key, value)`: Sets the tag to a string value, overwriting a potential previous value. Removing a key is SDK-defined, either with a `remove_tag` function or by passing nothing as data.
 
 - `scope.set_tags(tags)`: Sets an object with key/value pairs, convenience function instead of multiple `set_tag` calls.

docs/platforms/javascript/common/configuration/integrations/index.mdx

@@ -20,7 +20,6 @@ To disable system integrations, set `defaultIntegrations: false` when calling `i
 
 To override their settings, provide a new instance with your config to the `integrations` option. For example, to turn off browser capturing console calls:
 
-
 ```javascript
 Sentry.init({
   dsn: "___PUBLIC_DSN___",
@@ -62,7 +61,6 @@ You can add the integration with a dynamic import using `import()`. This method
 You can also lazy-load pluggable integrations via `Sentry.lazyLoadIntegration()`. This will attempt to load the integration from the Sentry CDN.
 Note that this function will reject if it fails to load the integration from the Sentry CDN, which can happen if a user has an ad-blocker or if there's a network problem. You should always make sure that rejections are handled for this function in your application.
 
-
 ```javascript
 async function loadHttpClient() {
   const httpClientIntegration = await Sentry.lazyLoadIntegration(
@@ -82,13 +80,11 @@ Lazy loading is available for the following integrations:
 - `captureConsoleIntegration`
 - `contextLinesIntegration`
 - `linkedErrorsIntegration`
-- `debugIntegration`
 - `dedupeIntegration`
 - `extraErrorDataIntegration`
 - `httpClientIntegration`
 - `reportingObserverIntegration`
 - `rewriteFramesIntegration`
-- `sessionTimingIntegration`
 - `browserProfilingIntegration`
 
 </PlatformCategorySection>

docs/platforms/javascript/common/configuration/integrations/trpc.mdx

@@ -59,4 +59,11 @@ const sentrifiedProcedure = t.procedure.use(sentryMiddleware);
 
 _Type: `boolean`_
 
-Defaults to `false`. If enabled, the RPC input will be captured in reported events.
+Defaults to `false`. If enabled, the RPC input will be captured in error events as `trpc` context.
+
+<Alert level="info" title="Truncated Input">
+
+If you observe nested objects in the `trpc` context being truncated with "`[Object]`", you can define a <PlatformLink to="/configuration/options/#normalizeDepth">`normalizeDepth` value</PlatformLink> to allow for more deeply nested objects in context.
+Note that the default depth for `trpc` context is 5.
+
+</Alert>

docs/platforms/javascript/guides/electron/index.mdx

@@ -28,7 +28,7 @@ Select which Sentry features you'd like to install in addition to Error Monitori
 
 Once configured, all unhandled exceptions and native crashes are automatically captured by Sentry.
 
-**Important:** Note your DSN. The _DSN_ (Data Source Name) tells the SDK where to send events. If you forget it, view _Settings -> Projects -> Client Keys (DSN)_ in the Sentry web UI.
+**Important:** Note your DSN. The DSN (Data Source Name) tells the SDK where to send events. If you forget it, view _Settings -> Projects -> Client Keys (DSN)_ in the Sentry web UI.
 
 ## Wizard
 

docs/platforms/python/configuration/options.mdx

@@ -64,7 +64,7 @@ Configures the sample rate for error events, in the range of `0.0` to `1.0`. The
 
 Dynamically configures the sample rate for error events on a per-event basis. This configuration option accepts a function, which takes two parameters (the `event` and the `hint`), and which returns a boolean (indicating whether the event should be sent to Sentry) or a floating-point number between `0.0` and `1.0`, inclusive (where the number indicates the probability the event is sent to Sentry; the SDK will randomly decide whether to send the event with the given probability).
 
-If this configuration option is specified, the <PlatformIdentifier name="sample_rate" /> option is ignored.
+If this configuration option is specified, the `sample_rate` option is ignored.
 
 </SdkOption>
 
@@ -99,7 +99,7 @@ If you enable this option, be sure to manually remove what you don't want to sen
 
 <SdkOption name="event_scrubber" type='sentry_sdk.scrubber.EventScrubber' defaultValue='None'>
 
-Scrubs the event payload for sensitive information such as cookies, sessions, and passwords from a `denylist`. It can additionally be used to scrub from another `pii_denylist` if <PlatformIdentifier name="send_default_pii" /> is disabled. See how to [configure the scrubber here](../../data-management/sensitive-data/#event-scrubber).
+Scrubs the event payload for sensitive information such as cookies, sessions, and passwords from a `denylist`. It can additionally be used to scrub from another `pii_denylist` if `send_default_pii` is disabled. See how to [configure the scrubber here](../../data-management/sensitive-data/#event-scrubber).
 
 </SdkOption>
 
@@ -153,7 +153,7 @@ Sentry differentiates stack frames that are directly related to your application
 
 A list of string prefixes of module names that do not belong to the app, but rather to third-party packages. Modules considered not part of the app will be hidden from stack traces by default.
 
-This option can be overridden using <PlatformIdentifier name="in_app_include" />.
+This option can be overridden using `in_app_include`.
 
 </SdkOption>
 
@@ -323,17 +323,17 @@ sentry_sdk.init(
 
 <SdkOption name="traces_sample_rate" type='float' defaultValue='None'>
 
-A number between `0` and `1`, controlling the percentage chance a given transaction will be sent to Sentry. (`0` represents 0% while `1` represents 100%.) Applies equally to all transactions created in the app. Either this or <PlatformIdentifier name="traces_sampler" /> must be defined to enable tracing.
+A number between `0` and `1`, controlling the percentage chance a given transaction will be sent to Sentry. (`0` represents 0% while `1` represents 100%.) Applies equally to all transactions created in the app. Either this or `traces_sampler` must be defined to enable tracing.
 
-If <PlatformIdentifier name="traces_sample_rate" /> is `0`, this means that no new traces will be created. However, if you have another service (for example a JS frontend) that makes requests to your service that include trace information, those traces will be continued and thus transactions will be sent to Sentry.
+If `traces_sample_rate` is `0`, this means that no new traces will be created. However, if you have another service (for example a JS frontend) that makes requests to your service that include trace information, those traces will be continued and thus transactions will be sent to Sentry.
 
-If you want to disable all tracing you need to set <PlatformIdentifier name="traces_sample_rate" />`=None`. In this case, no new traces will be started and no incoming traces will be continued.
+If you want to disable all tracing you need to set `traces_sample_rate=None`. In this case, no new traces will be started and no incoming traces will be continued.
 
 </SdkOption>
 
 <SdkOption name="traces_sampler" type='function' defaultValue='None'>
 
-A function responsible for determining the percentage chance a given transaction will be sent to Sentry. It will automatically be passed information about the transaction and the context in which it's being created, and must return a number between `0` (0% chance of being sent) and `1` (100% chance of being sent). Can also be used for filtering transactions, by returning `0` for those that are unwanted. Either this or <PlatformIdentifier name="traces_sample_rate" /> must be defined to enable tracing.
+A function responsible for determining the percentage chance a given transaction will be sent to Sentry. It will automatically be passed information about the transaction and the context in which it's being created, and must return a number between `0` (0% chance of being sent) and `1` (100% chance of being sent). Can also be used for filtering transactions, by returning `0` for those that are unwanted. Either this or `traces_sample_rate` must be defined to enable tracing.
 
 </SdkOption>
 
@@ -345,7 +345,7 @@ The option may contain a list of strings or regex against which the URLs of outg
 If one of the entries in the list matches the URL of an outgoing request, trace data will be attached to that request.
 String entries do not have to be full matches, meaning the URL of a request is matched when it _contains_ a string provided through the option.
 
-If <PlatformIdentifier name="trace_propagation_targets" /> is not provided, trace data is attached to every outgoing request from the instrumented client.
+If `trace_propagation_targets` is not provided, trace data is attached to every outgoing request from the instrumented client.
 
 </SdkOption>
 

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

@@ -73,6 +73,40 @@ When you point your browser to [http://localhost:8000/hello](http://localhost:80
 
 It takes a couple of moments for the data to appear in [sentry.io](https://sentry.io).
 
+## Options
+
+By adding `LitestarIntegration` to your `sentry_sdk.init()` call explicitly, you can set options for `LitestarIntegration` to change its behavior:
+
+```python
+import sentry_sdk
+from sentry_sdk.integrations.litestar import LitestarIntegration
+
+sentry_sdk.init(
+    # ...
+    integrations=[
+        LitestarIntegration(
+            failed_request_status_codes={403, *range(500, 599)},
+        ),
+    ],
+)
+```
+
+You can pass the following keyword arguments to `LitestarIntegration()`:
+
+### `failed_request_status_codes`
+
+A `set` of integers that will determine when an `HTTPException` should be reported to Sentry. The `HTTPException` is reported to Sentry if its status code is contained in the `failed_request_status_codes` set.
+
+Examples of valid `failed_request_status_codes`:
+
+- `{500}` will only report `HTTPException` with status 500.
+- `{400, *range(500, 600)}` will report `HTTPException` with status 400 as well as those in the 5xx range.
+- `set()` (the empty set) will not report any `HTTPException` to Sentry.
+
+The default is `{*range(500, 600)}`, meaning that any `HTTPException` with a status in the 5xx range is reported to Sentry.
+
+Regardless of how `failed_request_status_codes` is set, any exceptions raised by the handler, which are not of type `HTTPException` (or a subclass) are reported to Sentry. For example, if your request handler raises an unhandled `AttributeError`, the `AttributeError` gets reported to Sentry, even if you have set `failed_request_status_codes=set()`.
+
 ## Supported Versions
 
 <Alert level="warning" title="Note">