## Problem
Unified Logs does not expose Workers logs, so users cannot search
Workers ingress, runtime, or build events alongside other services.
## Fix
Add a Workers log type that classifies all three Workers OTEL streams.
Gate the option and any persisted Workers filters with the existing
Workers feature flag.
## How to test
- Enable the Workers feature flag and open Unified Logs.
- Select Workers from the Log Type filter.
- Expected result: Unified Logs shows ingress, runtime, and build events
with the Workers icon.
- Disable the Workers feature flag and load a URL containing
`log_type:eq:workers`.
- Expected result: the Workers option and filter are removed, and
Workers logs are not queried.
- Run `./node_modules/.bin/vitest --run
components/interfaces/UnifiedLogs/UnifiedLogs.queries.test.ts
components/interfaces/UnifiedLogs/UnifiedLogs.utils.test.ts
data/workers/worker-logs-query.test.ts` from `apps/studio`.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added Workers as a selectable log type in Unified Logs.
* Unified Logs now combines worker ingress, guest, and API streams under
the Workers category.
* Added a dedicated Workers icon and worker log filtering.
* **Improvements**
* Worker filters and URL parameters respect feature availability.
* Worker details show relevant metadata while omitting unavailable HTTP
fields.
* Improved handling of worker log levels, statuses, and raw data.
* Added stronger validation for unified log data.
* **Tests**
* Added coverage for worker routing, filtering, feature visibility,
parsing, and metadata redaction.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
Workers log views were limited to the most recent 24 hours and could not
be narrowed by event text or HTTP method.
## Fix
Adds selectable time ranges, event-message search, and an HTTP-method
filter for invocation logs. Filters are applied in the analytics query
and included in the cache key.
## How to test
- Open a worker and select the Invocations tab.
- Change the time range, enter an event message, and select a method.
- Expected result: only matching invocation logs are shown.
- Open Logs or Activity.
- Expected result: message and time filters are available; the method
filter is hidden.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added worker log filtering by date range and event message.
* Applied a default 24-hour time range to log searches.
* Improved filter controls and updated empty-state messaging to reflect
the selected range.
* **Bug Fixes**
* Improved filtering accuracy and safer handling of special characters
in event messages.
* **Tests**
* Added coverage for date-range and message-filter query behavior.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
The Workers view can remain stale after a worker is deployed through the
CLI, because the dashboard has no deployment mutation to invalidate its
list query.
## Fix
Add a manual Refresh action to the Workers header and force the Workers
list query to refetch whenever the browser regains focus.
## How to test
- Open a project’s Workers view and select Refresh.
- Expected result: the list requests current worker data and renders it.
- Deploy a worker through the CLI, then return focus to the Workers
view.
- Expected result: the Workers list refreshes even when its cached data
is fresh.
Closes FE-4323.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Added Refresh buttons to the Workers page and worker list.
- Refreshing displays the latest worker information and shows a loading
state while data is retrieved.
- Worker data now automatically refreshes when the browser window
regains focus.
- Added a Refresh action to unexpected-error messages, allowing failed
requests to be retried without leaving the page.
- **Bug Fixes**
- Improved recovery from failed worker data requests through in-page
retry support.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What
The worker detail page at `/project/[ref]/workers/[name]`, reading `GET
/v2/projects/{ref}/workers/{name}`. Base: #49194.
## How to test
Only on the **Mockamaster** project in staging — it is the one project
in the alpha allow-list.
1. Staging dashboard → Mockamaster → **Workers** → click
`dashboard-test`
2. Overview: instances read 1 declared / 1 live / 1 ready / 0 stale, no
error alerts
3. Settings: Deno 2, `denoland/deno:latest`, 2 GB · 1 vCPU, private, US
West (locked)
4. **How to call** in the header → the snippets name the real worker URL
No write actions. Delete (FE-4190) is deliberately out.
Closes FE-4189
Closes FE-4197
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added worker detail pages with overview, requests, logs, builds, and
settings tabs.
* Added worker metadata, runtime details, invocation examples, and local
development commands.
* Added worker log streams with refresh, row selection, loading, empty,
and error states.
* Added worker-specific log formatting and clearer instance status
information.
* **Documentation**
* Updated migration tracking to mark the worker route as complete.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What
The Workers list page at `/project/[ref]/workers`, behind
`useFlag('workers')`. Reads `GET /v2/projects/{ref}/workers`.
- Sidebar and command-menu entries, both hidden when the flag is off
- Name search, state and access filters, pagination
- Read-only
Gating, in order: flag off redirects to the project home; a 404 from the
API means the project is outside the alpha allow-list ("not enabled for
this project"); a 403 means the caller lacks the permission
(`NoPermission`); anything else is an `AlertError`.
`parseWorker` in `data/workers/workers.utils.ts` is the only place the
API shape becomes the view model. It validates with zod, so a drifted
response fails the query instead of half-rendering a row.
## How to test
Only on the **Mockamaster** project in staging — it is the one project
in the alpha allow-list, and standing a worker up anywhere else is
involved right now.
1. Staging dashboard → Mockamaster → **Compute** in the sidebar
2. Expect the `dashboard-test` worker: state `Active`, runtime Deno,
private, US West, 2 GB · 1 vCPU · 1 inst
3. Open any other project's `/workers` URL → "Compute is not enabled for
this project"
4. Turn the `workers` flag off → the sidebar entry disappears and the
URL redirects to the project home
Closes FE-4188
Jordi Enric