feat(webapp): default the queue metrics period to 1 hour and remember it by ericallam · Pull Request #4438 · triggerdotdev/trigger.dev

ericallam · 2026-07-31T09:42:22Z

Summary

The Queues list and queue detail pages opened on a 1 day window, and went back to it every time you navigated between queues or reloaded. They now default to the last hour, and the period you pick is remembered across navigations and refreshes.

Design

The last period is stored in a queueMetricsPeriod cookie, written client-side whenever a period lands in the URL and read by both loaders. A cookie rather than localStorage because the queues list renders its per-queue metrics columns server-side: with localStorage the page would paint the 1 hour default and then re-fetch, and the picker would flash the wrong window.

Both pages resolve the window once, in one place, and pass it down:

period: resolveQueueMetricsPeriod({
  period: value("period"),   // a usable period in the URL wins
  from: value("from"),       // an absolute range means "no period"
  to: value("to"),
  defaultPeriod,             // otherwise the remembered default from the loader
}),

That keeps the picker pill and every chart query on the same value, so no call site falls back to its own default. Periods the picker could never produce (a hand-edited ?period=garbage, or a window past the 30 day retention) fall back to the default, and the picker renders the resolved window rather than the raw search param so the label can't disagree with the data. Absolute from/to ranges, including drag-to-zoom, are not remembered, since they would pin later visits to a window that has gone stale.

While wiring that up: the two queue-metric queries that go straight to ClickHouse (the list table and the concurrency-keys endpoint) never applied the org's queryPeriodDays limit, so a hand-typed ?period= read further back than the plan allows. Everything behind /resources/metric is already clipped that way by executeQuery; both of these now clip with the same limit, capped at the retention window, and the plan cap is resolved once per load and handed to the page instead of each route deriving its own copy from the client-side subscription.

Verified on both pages: default with no cookie is 1 hr, picking 6 hrs survives navigating away and back to a param-free URL and a hard reload, clearing the cookie returns to 1 hr, an oversized period falls back without being remembered, and an absolute range still renders as a range.

changeset-bot · 2026-07-31T09:42:29Z

⚠️ No Changeset found

Latest commit: c699187

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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

coderabbitai · 2026-07-31T09:43:57Z

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

@coderabbitai resume to resume automatic reviews.
@coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

▶️ Resume reviews
🔍 Trigger review

Walkthrough

Queue metrics now use shared period utilities. The utilities validate periods, read remembered periods from cookies, persist valid selections, resolve URL or default values, apply organization limits, and clip query windows. Queue list and queue detail pages derive defaults from requests, resolve metric ranges, and remember selected periods. Metric cards and concurrency-key resources use the shared default period and query-window limits. A changelog entry documents the behavior.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main changes: a 1-hour default period and remembered queue metrics selection.
Description check	✅ Passed	The description explains the changes, design decisions, affected behavior, and testing results, despite omitting the template checklist and screenshots.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches 💡 2

📝 Generate docstrings 💡

Create stacked PR
Commit on current branch

🛠️ Fix failing CI checks 💡

Fix failing CI checks

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch feat/queue-metrics-default-period-1h

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

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

The Queues list and queue detail pages opened on a 1 day window and reset to it on every navigation. They now default to 1 hour, and the last period picked is kept in a cookie the loaders read, so the first render is already on the remembered window instead of painting the default and re-fetching. Both pages resolve the period once (URL param, then absolute range, then the remembered default) and pass it down, so the picker and every chart query agree on one value. Absolute from/to ranges are not remembered.

…c periods A hand-edited `?period=garbage` or `?period=9999d` was passed straight to the metric queries, so the charts and the SSR'd table could end up on different windows. Period resolution now rejects anything the picker could not produce (including windows past the 30 day retention), and the queues list loader resolves through the same path the client queries use.

The queue-metric queries that go straight to ClickHouse (the queues list table and the concurrency-keys endpoint) never applied the org's query-period limit, so a hand-typed `?period=` could read further back than the plan allows. Every query through executeQuery is already clipped this way; both of these now clip with the same limit, capped at the 30 day retention. A remembered period longer than the plan allows is clamped to the plan maximum, and the picker now renders the resolved window rather than the raw search param, so the label can no longer disagree with the data on screen. The plan cap is resolved once per load and handed to the page, replacing the copy each route derived from the client-side subscription.

pkg-pr-new · 2026-07-31T14:14:18Z

Open in StackBlitz

@trigger.dev/build

npm i https://pkg.pr.new/@trigger.dev/build@e59f65a

trigger.dev

npm i https://pkg.pr.new/trigger.dev@e59f65a

@trigger.dev/core

npm i https://pkg.pr.new/@trigger.dev/core@e59f65a

@trigger.dev/python

npm i https://pkg.pr.new/@trigger.dev/python@e59f65a

@trigger.dev/react-hooks

npm i https://pkg.pr.new/@trigger.dev/react-hooks@e59f65a

@trigger.dev/redis-worker

npm i https://pkg.pr.new/@trigger.dev/redis-worker@e59f65a

@trigger.dev/rsc

npm i https://pkg.pr.new/@trigger.dev/rsc@e59f65a

@trigger.dev/schema-to-json

npm i https://pkg.pr.new/@trigger.dev/schema-to-json@e59f65a

@trigger.dev/sdk

npm i https://pkg.pr.new/@trigger.dev/sdk@e59f65a

commit: e59f65a

A date range that ends before the plan's earliest queryable time had its start pulled forward past its own end, sending an inverted window to ClickHouse. It now collapses to an empty window, which is what the enforced lower bound in executeQuery produces for the same request: no rows.

The period pattern only accepted a count of up to four digits, so a custom duration the picker allows (10000 minutes, a little under 7 days) was treated as unusable and quietly replaced with the default. The count is now unbounded and the retention bound is what rules a window out. Resolution also clamps the period from the URL, not just the remembered default, so a period wider than the plan's query period shows the window the data actually covers instead of the one that was asked for. The plan lookup reads through the limit cache and is skipped entirely on the classic Queues page, which has no time filter: the page revalidates on an interval, so an uncached platform call would repeat for the life of the tab.

…es it Rounding the plan's query period up to a whole day would have let these pages read further back than every other metric query for a sub-day limit. The budget is now used as-is, matching the bound executeQuery enforces, and the period string derived from it steps down to hours or minutes so a fractional budget still yields a window inside it.

The query-period lookup runs before the block that renders the Queues page without metrics when ClickHouse is unavailable, so a failure reading the limit would have cost the whole page rather than the time filter. It now falls back to the retention cap, which is the widest window the data can cover anyway.