fix(dashboard): apply time filter preset periods immediately on click by nicktrn · Pull Request #3053 · triggerdotdev/trigger.dev

nicktrn · 2026-02-13T18:22:49Z

Extract applyPeriod callback from applySelection so preset period buttons ("Created in the last X") apply immediately when clicked, instead of only updating the selection state and requiring a separate apply step.

Also validates maxPeriodDays on instant-apply so the upgrade prompt still works correctly for plan-limited periods.

Validation still works:

Extract applyPeriod callback from applySelection so preset period buttons ("Created in the last X") apply immediately when clicked instead of requiring a separate apply step.

changeset-bot · 2026-02-13T18:22:53Z

⚠️ No Changeset found

Latest commit: 96edc77

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-02-13T18:23:14Z

Walkthrough

This change refactors the SharedFilters.tsx component to introduce a new applyPeriod helper function that centralizes validation and navigation logic for applying time periods. The previous combined validation-and-navigation logic has been split into separate functions. The duration and date range handling paths are restructured, with enhanced max period validation now performed within applyPeriod. A new optional applyPeriod prop is added to the public API of TimeDropdown, enabling external control of period application. Preset duration buttons now invoke applyPeriod instead of directly mutating state, while custom duration inputs continue to update internal state before application through the centralized function.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

🚥 Pre-merge checks | ✅ 2 | ❌ 2

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The PR description is incomplete. Required sections like Testing, Changelog, and Closes issue are missing or largely unfilled.	Add the required sections: Closes # reference, Testing steps, Changelog description, and complete the checklist items to match the repository template.
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main change: extracting and applying time filter preset periods immediately on click, which is the primary objective of the PR.
Merge Conflict Detection	✅ Passed	✅ No merge conflicts detected when merging into `main`

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

📝 Generate docstrings

🧪 Generate unit tests (beta)

Create PR with unit tests
Post copyable unit tests in a comment
Commit unit tests in branch fix/time-filter-instant-apply

No actionable comments were generated in the recent review. 🎉

🧹 Recent nitpick comments

apps/webapp/app/components/runs/v3/SharedFilters.tsx (2)

540-559: Minor: double maxPeriodDays validation for the applySelection → applyPeriod path.

When applySelection is invoked (via the Apply button), exceedsMaxPeriod at line 543 will catch over-limit periods before applyPeriod is reached at line 559. The check inside applyPeriod (line 507) is therefore redundant on this path — though it's essential for the direct-call path from preset buttons. Not a bug, just something to be aware of.

698-726: Preset buttons now apply instantly — validation error display is safe but slightly asymmetric.

When a preset exceeding maxPeriodDays is clicked, applyPeriod sets validationError (line 508), but the inline error at line 728 only renders when selectedPeriod === "custom". The user still gets feedback via the exceedsMaxPeriod callout (line 866), so the UX is correct. The orphaned validationError string gets cleared by subsequent interactions (focus/change handlers all call setValidationError(null)).

This works, but if you wanted tighter hygiene you could skip setValidationError inside applyPeriod for preset paths and rely solely on the callout. Not blocking.

📜 Recent review details

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between a3d3b17 and 96edc77.

📒 Files selected for processing (1)

apps/webapp/app/components/runs/v3/SharedFilters.tsx

🧰 Additional context used

📓 Path-based instructions (6)

**/*.{ts,tsx}

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

**/*.{ts,tsx}: Use types over interfaces for TypeScript
Avoid using enums; prefer string unions or const objects instead

**/*.{ts,tsx}: Always import tasks from @trigger.dev/sdk, never use @trigger.dev/sdk/v3 or deprecated client.defineJob pattern
Every Trigger.dev task must be exported and have a unique id property with no timeouts in the run function

Files:

apps/webapp/app/components/runs/v3/SharedFilters.tsx

{packages/core,apps/webapp}/**/*.{ts,tsx}

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

Use zod for validation in packages/core and apps/webapp

Files:

apps/webapp/app/components/runs/v3/SharedFilters.tsx

**/*.{ts,tsx,js,jsx}

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

Use function declarations instead of default exports

Import from @trigger.dev/core using subpaths only, never import from root

Files:

apps/webapp/app/components/runs/v3/SharedFilters.tsx

apps/webapp/app/**/*.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/webapp.mdc)

Access all environment variables through the env export of env.server.ts instead of directly accessing process.env in the Trigger.dev webapp

Files:

apps/webapp/app/components/runs/v3/SharedFilters.tsx

apps/webapp/**/*.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/webapp.mdc)

apps/webapp/**/*.{ts,tsx}: When importing from @trigger.dev/core in the webapp, use subpath exports from the package.json instead of importing from the root path
Follow the Remix 2.1.0 and Express server conventions when updating the main trigger.dev webapp

Access environment variables via env export from apps/webapp/app/env.server.ts, never use process.env directly

Files:

apps/webapp/app/components/runs/v3/SharedFilters.tsx

**/*.{js,ts,jsx,tsx,json,md,yaml,yml}

📄 CodeRabbit inference engine (AGENTS.md)

Format code using Prettier before committing

Files:

apps/webapp/app/components/runs/v3/SharedFilters.tsx

🧠 Learnings (3)

📓 Common learnings

Learnt from: matt-aitken
Repo: triggerdotdev/trigger.dev PR: 2953
File: apps/webapp/app/components/runs/v3/SharedFilters.tsx:441-452
Timestamp: 2026-01-28T14:15:15.011Z
Learning: In apps/webapp/app/components/runs/v3/SharedFilters.tsx, the maxPeriodDays limit for date ranges should only check the from date (via dateRangeToDays(fromValue)) because it enforces data retention limits—how far back in history queries can reach. The to date is irrelevant for retention-based limits.

📚 Learning: 2026-01-28T14:15:09.778Z

Learnt from: matt-aitken
Repo: triggerdotdev/trigger.dev PR: 2953
File: apps/webapp/app/components/runs/v3/SharedFilters.tsx:441-452
Timestamp: 2026-01-28T14:15:09.778Z
Learning: In apps/webapp/app/components/runs/v3/SharedFilters.tsx, enforce the maxPeriodDays limit based only on the from date (fromValue) using dateRangeToDays(fromValue) to reflect data retention limits. The to date should be ignored for retention checks. Ensure any retention-window logic or validations rely solely on the fromValue, and update related comments/tests if needed.

Applied to files:

apps/webapp/app/components/runs/v3/SharedFilters.tsx

📚 Learning: 2026-02-11T16:37:32.429Z

Learnt from: matt-aitken
Repo: triggerdotdev/trigger.dev PR: 3019
File: apps/webapp/app/components/primitives/charts/Card.tsx:26-30
Timestamp: 2026-02-11T16:37:32.429Z
Learning: In projects using react-grid-layout, avoid relying on drag-handle class to imply draggability. Ensure drag-handle elements only affect dragging when the parent grid item is configured draggable in the layout; conditionally apply cursor styles based on the draggable prop. This improves correctness and accessibility.

Applied to files:

apps/webapp/app/components/runs/v3/SharedFilters.tsx

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (26)

GitHub Check: units / internal / 🧪 Unit Tests: Internal (3, 8)
GitHub Check: units / internal / 🧪 Unit Tests: Internal (8, 8)
GitHub Check: units / internal / 🧪 Unit Tests: Internal (4, 8)
GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (3, 8)
GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (6, 8)
GitHub Check: units / internal / 🧪 Unit Tests: Internal (6, 8)
GitHub Check: units / internal / 🧪 Unit Tests: Internal (7, 8)
GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (4, 8)
GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (1, 8)
GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (7, 8)
GitHub Check: units / internal / 🧪 Unit Tests: Internal (2, 8)
GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (8, 8)
GitHub Check: units / internal / 🧪 Unit Tests: Internal (5, 8)
GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - pnpm)
GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (5, 8)
GitHub Check: sdk-compat / Node.js 20.20 (ubuntu-latest)
GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (2, 8)
GitHub Check: units / packages / 🧪 Unit Tests: Packages (1, 1)
GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
GitHub Check: sdk-compat / Cloudflare Workers
GitHub Check: sdk-compat / Deno Runtime
GitHub Check: sdk-compat / Node.js 22.12 (ubuntu-latest)
GitHub Check: sdk-compat / Bun Runtime
GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
GitHub Check: typecheck / typecheck

🔇 Additional comments (3)

apps/webapp/app/components/runs/v3/SharedFilters.tsx (3)

503-538: Clean extraction of applyPeriod — logic looks correct.

The centralized validation → apply → close flow is well-structured. Both controlled (onValueChange) and URL (replace) modes are handled consistently, and date range state is properly cleared when applying a period.

489-501: Retention check correctly uses only fromValue for date ranges.

The exceedsMaxPeriod computation at line 499 checks dateRangeToDays(fromValue) without considering the to date, which aligns with the retention-window semantics. Based on learnings, the maxPeriodDays limit should only check the from date to reflect data retention limits.

423-447: AI summary is inaccurate: applyPeriod is not a new prop on TimeDropdown.

The summary claims applyPeriod is exposed as a new optional prop, but in the actual code it's an internal useCallback defined within the component (line 503). The public API of TimeDropdown is unchanged. No action needed — just flagging the discrepancy.

_{✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.}

Tip

Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord.

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 and usage tips.}

devin-ai-integration

Devin Review found 1 potential issue.

apps/webapp/app/components/runs/v3/SharedFilters.tsx

fix(dashboard): apply time filter preset periods immediately on click

96edc77

Extract applyPeriod callback from applySelection so preset period buttons ("Created in the last X") apply immediately when clicked instead of requiring a separate apply step.

myftija approved these changes Feb 13, 2026

View reviewed changes

devin-ai-integration bot reviewed Feb 13, 2026

View reviewed changes

apps/webapp/app/components/runs/v3/SharedFilters.tsx Show resolved Hide resolved

nicktrn merged commit 1d744fa into main Feb 13, 2026
42 checks passed

nicktrn deleted the fix/time-filter-instant-apply branch February 13, 2026 18:35

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(dashboard): apply time filter preset periods immediately on click#3053

fix(dashboard): apply time filter preset periods immediately on click#3053
nicktrn merged 1 commit intomainfrom
fix/time-filter-instant-apply

nicktrn commented Feb 13, 2026 •

edited

Loading

Uh oh!

changeset-bot bot commented Feb 13, 2026

Uh oh!

coderabbitai bot commented Feb 13, 2026 •

edited

Loading

Uh oh!

devin-ai-integration bot left a comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

nicktrn commented Feb 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

changeset-bot bot commented Feb 13, 2026

⚠️ No Changeset found

Uh oh!

coderabbitai bot commented Feb 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Walkthrough

Estimated code review effort

Uh oh!

devin-ai-integration bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

nicktrn commented Feb 13, 2026 •

edited

Loading

coderabbitai bot commented Feb 13, 2026 •

edited

Loading