feat(webapp,core,cli): filter runs by region in dashboard, API, and MCP

[ericallam]

Summary

Adds a Region column and Region filter (under More filters) to the runs list dashboard, the same filter on the public runs list API (filter[region]), and a matching region input on the MCP list_runs tool. Each run's executing region is also surfaced as a new optional region field on the runs list and run retrieve responses, populated from the worker instance group's masterQueue identifier.

Useful when you run tasks across multiple regions and want to slice the runs list — or your existing run-querying scripts — by where the run actually executed.

Design

The filter value in the URL / API is the masterQueue identifier (the same string already persisted on TaskRun and replicated to ClickHouse as worker_queue), so the query just becomes worker_queue IN (...) with no server-side translation. The Region dropdown options come from a new resource loader backed by RegionsPresenter, which now also exposes masterQueue alongside the existing region metadata.

// public API
const runs = await runs.list({ region: ["us-east-1", "eu-west-1"] });
// each item: { id, status, ..., region?: "us-east-1" }

// MCP
list_runs({ environment: "prod", region: "us-east-1" })

Test plan

• Dashboard: open the runs list, confirm the new Region column renders the friendly region name (or – for legacy runs with empty masterQueue).
• Dashboard: open More filters → Region, multi-select a couple of regions, confirm the URL gains ?regions=<masterQueue> and the list narrows.
• Combine with Queues / Statuses / time filters — no interaction regressions.
• API: GET /api/v1/runs?filter[region]=<masterQueue> returns only matching runs, and each item has a region field set.
• API: GET /api/v1/runs/<id> returns region for a run that has a non-empty workerQueue.
• MCP: call list_runs with region: "..."; verify the formatted output line includes region:<value>.

---

This is part 1 of 5 in a stack made with GitButler:

•  5  feat(webapp,core,cli): filter runs by region in dashboard, API, and MCP #3612 👈
•  4  feat: ai-chat reference project + MCP agent-chat tooling (4/4) #3546
•  3  feat(webapp): agent-view dashboard for chat.agent runs (3/4) #3545
•  2  feat(sdk): chat.agent — runtime + browser transport (2/4) #3543
•  1  feat: Sessions dashboard, task_kind, and chat-ready hardening (1/4) #3542

[changeset-bot]

🦋 Changeset detected

Latest commit: 2493552

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 32 packages

Name	Type
trigger.dev	Patch
@trigger.dev/core	Patch
@trigger.dev/sdk	Patch
references-ai-chat	Patch
d3-chat	Patch
references-d3-openai-agents	Patch
references-nextjs-realtime	Patch
references-realtime-hooks-test	Patch
references-realtime-streams	Patch
references-telemetry	Patch
@trigger.dev/build	Patch
@trigger.dev/plugins	Patch
@trigger.dev/python	Patch
@trigger.dev/redis-worker	Patch
@trigger.dev/schema-to-json	Patch
@internal/cache	Patch
@internal/clickhouse	Patch
@internal/llm-model-catalog	Patch
@trigger.dev/rbac	Patch
@internal/redis	Patch
@internal/replication	Patch
@internal/run-engine	Patch
@internal/schedule-engine	Patch
@internal/testcontainers	Patch
@internal/tracing	Patch
@internal/tsql	Patch
@internal/zod-worker	Patch
@internal/sdk-compat-tests	Patch
@trigger.dev/react-hooks	Patch
@trigger.dev/rsc	Patch
@trigger.dev/database	Patch
@trigger.dev/otlp-importer	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: d828f002-29eb-4c9f-bae7-e24d63a04ee1

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/runs-list-region-filter

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[devin-ai-integration]

Devin Review found 3 potential issues.

View 2 additional findings in Devin Review.

[devin-ai-integration]

🟡 Missing regions in hasFilters check prevents "Clear all filters" button from appearing

The hasFilters variable in RunsFilters (apps/webapp/app/components/runs/v3/RunFilters.tsx:377-389) determines whether the "Clear all filters" button is shown. The PR added regions as a new filter type throughout the codebase (filter menu, applied filter pill, search params parsing, ClickHouse query, etc.) but did not add searchParams.has("regions") to this check. When a user applies only a region filter, the "Clear all filters" button will not appear, leaving the user without a quick way to reset filters.

(Refers to lines 377-389)

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🚩 Other TaskRunsTable call sites don't pass regions prop — graceful fallback

The TaskRunsTable component is used in three other routes (errors, waitpoints, schedules) that don't pass the new regions prop. Since regions defaults to undefined and the regionByMasterQueue map is built from regions ?? [], this is safe. The region column will still appear for non-DEVELOPMENT environments, but will show raw masterQueue strings (e.g. 'us-east-1') instead of friendly names with flag icons. This is an acceptable degradation — the data is still correct, just less pretty.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🚩 ApiRetrieveRunPresenter exposes workerQueue as region for both detail and related runs

In createCommonRunStructure at apps/webapp/app/presenters/v3/ApiRetrieveRunPresenter.server.ts:467, region: run.workerQueue || undefined is set. Since commonRunSelect now includes workerQueue: true and createCommonRunStructure is used for both the main run and related runs (parent/root/children), the region field will appear on all related run objects in the API response. The workerQueue column has a Prisma @default("main") so it will always have a value — meaning region will be set to "main" for most runs rather than undefined. This is the || undefined check using falsy, and since "main" is truthy, it will pass through. This seems intentional but worth noting: even runs that haven't been assigned to a specific region will show "main" as their region.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

Devin Review found 1 new potential issue.

View 4 additional findings in Devin Review.

[devin-ai-integration]

🚩 ClickHouse vs Prisma data inconsistency for pre-existing runs' region values

The Prisma schema defines workerQueue String @default("main"), so all pre-existing PostgreSQL rows have workerQueue = "main". However, the ClickHouse column worker_queue defaults to "" (empty string) per taskRuns.ts:50. The new ClickHouse filter (clickhouseRunsRepository.server.ts:328-330) queries worker_queue IN {regions}, which means filtering by region "main" would miss pre-migration ClickHouse rows (which have worker_queue = ""). Meanwhile, the dashboard table reads from Prisma and shows "main" for those same runs. This inconsistency only matters for runs created before the worker_queue column was populated in ClickHouse.

---

Was this helpful? React with 👍 or 👎 to provide feedback.