From 5efff8e0e50fce0ac6fa13c0b794dd36c6bf99a3 Mon Sep 17 00:00:00 2001 From: "inkeep[bot]" <257615677+inkeep[bot]@users.noreply.github.com> Date: Tue, 21 Jul 2026 22:11:40 +0000 Subject: [PATCH 1/2] docs(replay-vision): update running-scanners for bulk scan multi-select workflow --- contents/docs/replay-vision/running-scanners.mdx | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/contents/docs/replay-vision/running-scanners.mdx b/contents/docs/replay-vision/running-scanners.mdx index ee9980ff13bf..24b724a042c3 100644 --- a/contents/docs/replay-vision/running-scanners.mdx +++ b/contents/docs/replay-vision/running-scanners.mdx @@ -36,7 +36,7 @@ Sweeps run continuously – once a scanner is enabled, observations start accumu ### What happens when I change filters? -Changing a scanner's filters affects which **new** sessions match going forward. Old recordings aren't re-evaluated against the new filters. If you broaden the filters and want to backfill, trigger on-demand observations against the recordings you care about – the bulk [**Scan these recordings**](#from-the-recordings-list) action is the fastest way – or wait for new matches to come in. +Changing a scanner's filters affects which **new** sessions match going forward. Old recordings aren't re-evaluated against the new filters. If you broaden the filters and want to backfill, trigger on-demand observations against the recordings you care about – the bulk [**Scan N selected**](#from-the-recordings-list) action is the fastest way – or wait for new matches to come in. ### What happens when I disable the scanner? @@ -62,7 +62,11 @@ On-demand triggers: ### From the recordings list -To scan a batch in one go, select recordings in the [recordings list](/docs/session-replay/how-to-watch-recordings) and choose **Scan these recordings**, then pick a scanner. Each selected session is queued as its own observation. Sessions the scanner has already observed are skipped automatically, so re-scanning a selection is safe. +The On-demand tab's recordings table has a checkbox column for multi-select. Tick individual rows or use **select all on page**, then click **Scan N selected** in the selection bar. Each selected session is queued as its own observation. + +Recordings the scanner has already observed or that are currently in flight are greyed out and can't be selected — there's nothing to re-scan. + +The bulk action **scans what fits**: it starts as many observations as your [concurrency limits and monthly credit quota](/docs/replay-vision/quota-and-limits) allow, then reports the rest as skipped rather than failing the whole batch. A toast notification summarizes the outcome — how many started, plus any that were skipped or failed — so you know at a glance whether a partial run happened. This is also the fastest way to backfill after broadening a scanner's filters. From 6da1ca27ab821d0cb00d54cd2c93bf140c3c5e42 Mon Sep 17 00:00:00 2001 From: "inkeep[bot]" <257615677+inkeep[bot]@users.noreply.github.com> Date: Tue, 21 Jul 2026 22:13:10 +0000 Subject: [PATCH 2/2] docs(replay-vision): document bulk scan behavior in quota-and-limits PR #72678 added bulk on-demand scanning. Unlike single triggers (which return 402 on quota exhaustion), bulk scans start as many sessions as limits allow and report the rest as skipped_quota or skipped_limit. --- contents/docs/replay-vision/quota-and-limits.mdx | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/contents/docs/replay-vision/quota-and-limits.mdx b/contents/docs/replay-vision/quota-and-limits.mdx index 2e54278ccd59..f2867a3af369 100644 --- a/contents/docs/replay-vision/quota-and-limits.mdx +++ b/contents/docs/replay-vision/quota-and-limits.mdx @@ -48,10 +48,11 @@ In practice this means: **every observation that produces a `$recording_observed ## What happens when the cap is reached -Both enforcement paths use the same check: +Each enforcement path handles this differently: - **Background sweeps** – new observations queued by the automatic schedule are silently skipped. The scanner stays enabled, the sweep keeps running, but no work gets queued until quota frees up (next month, or as in-flight observations resolve to ineligible/failed). -- **On-demand triggers** – the player action and the `vision-scanners-scan-session` MCP tool return a `402 Payment Required` response with a `quota_limit_exceeded` code. +- **Single on-demand triggers** – the player action and the `vision-scanners-scan-session` MCP tool return a `402 Payment Required` response with a `quota_limit_exceeded` code. +- **Bulk on-demand scans** – the **Scan N selected** action starts as many scans as the quota and concurrency limits allow, then reports the remaining sessions as `skipped_quota` or `skipped_limit` rather than failing the entire batch. A scanner that's been silenced by the cap will resume producing observations automatically once usage drops below the cap (e.g. at the start of the next month).