feat(dashboard): Run list custom time intervals instead of just preset values #2849
Conversation
Allow users to specify custom time intervals (e.g., 90 minutes) instead of being limited to preset values. Adds a numeric input field with a unit dropdown (minutes/hours/days) that works with the existing parse-duration backend. Slack thread: https://triggerdotdev.slack.com/archives/C032WA2S43F/p1767877958977499?thread_ts=1767877851.170929&cid=C032WA2S43F
|
WalkthroughAdds parsing and state handling for custom time periods in SharedFilters: a Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes 🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
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. Comment |
Code Review: Custom Time Intervals FeatureThanks for this enhancement! Allowing users to specify custom time intervals is a great UX improvement over being limited to preset values. Here's my review: Overall AssessmentThe implementation is clean and well-structured. The code follows existing patterns in the codebase and integrates smoothly with the existing time filter system. Code Quality & Best PracticesStrengths:
Suggestions:
Potential Bugs or Issues
Performance ConsiderationsThe implementation is performant:
One minor note: Security ConcernsNo security issues identified. The custom period string is:
Test CoverageNo tests appear to be included in this PR. Consider adding:
UI/UX Notes
SummaryThis is a well-implemented feature that enhances user experience. The main recommendations are:
Nice work! 🎉 |
Review CompleteYour review story is ready! Comment !reviewfast on this PR to re-generate the story. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
apps/webapp/app/components/runs/v3/SharedFilters.tsx (2)
346-349: Consider simplifying the validation expression.The IIFE pattern works but is a bit verbose. This could be a direct boolean expression for clarity.
♻️ Suggested simplification
- const isCustomDurationValid = (() => { - const value = parseInt(customValue, 10); - return !isNaN(value) && value > 0; - })(); + const parsedCustomValue = parseInt(customValue, 10); + const isCustomDurationValid = !isNaN(parsedCustomValue) && parsedCustomValue > 0;
389-402: Consider addingstep="1"to indicate integer-only input.The validation correctly rejects non-integer values, but
type="number"allows decimal input by default. Addingstep="1"provides a browser hint and improves UX for users who might try entering fractional values.♻️ Suggested improvement
<input type="number" min="1" + step="1" placeholder="e.g. 90" value={customValue}
📜 Review details
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
📒 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
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
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
envexport ofenv.server.tsinstead of directly accessingprocess.envin 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/corein 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
Files:
apps/webapp/app/components/runs/v3/SharedFilters.tsx
**/*.{js,ts,jsx,tsx,json,md,css,scss}
📄 CodeRabbit inference engine (AGENTS.md)
Format code using Prettier
Files:
apps/webapp/app/components/runs/v3/SharedFilters.tsx
🧠 Learnings (1)
📚 Learning: 2025-12-18T14:09:10.154Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 2794
File: internal-packages/run-engine/src/engine/systems/debounceSystem.ts:390-397
Timestamp: 2025-12-18T14:09:10.154Z
Learning: In the debounce system (internal-packages/run-engine/src/engine/systems/debounceSystem.ts), millisecond delays are not supported. The minimum debounce delay is 1 second (1s). The parseNaturalLanguageDuration function supports w/d/hr/h/m/s units only.
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). (24)
- GitHub Check: Cursor Bugbot
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (5, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (4, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (2, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (8, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (6, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (3, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (7, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (7, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (5, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (2, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (3, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (8, 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 (6, 8)
- GitHub Check: typecheck / typecheck
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - npm)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
- GitHub Check: units / packages / 🧪 Unit Tests: Packages (1, 1)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - pnpm)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (6)
apps/webapp/app/components/runs/v3/SharedFilters.tsx (6)
98-111: LGTM!The
timeUnitsarray andparsePeriodStringhelper are well-structured. The regex correctly parses the supported duration formats, and returningnullfor invalid input provides safe fallback behavior.
193-215: LGTM!The enhanced period rendering logic properly handles both preset and custom periods with appropriate fallback behavior. The singular/plural formatting for custom durations is a nice UX touch.
275-284: LGTM!The initialization helper correctly parses the period and provides sensible defaults.
302-305: LGTM!The custom duration state initialization is correctly scoped. The input fields maintain their own state for user editing, which is appropriate for this controlled form pattern.
428-429: LGTM!The visual separator and descriptive label provide clear section organization.
478-486: LGTM!The Apply button correctly calls
applyDateRange()to persist the exact time range selection.
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
| // Custom duration state | ||
| const initialCustom = getInitialCustomDuration(period); | ||
| const [customValue, setCustomValue] = useState(initialCustom.value); | ||
| const [customUnit, setCustomUnit] = useState(initialCustom.unit); |
There was a problem hiding this comment.
Custom duration state not synced with period prop changes
Medium Severity
The customValue and customUnit state variables are initialized from getInitialCustomDuration(period), but useState only uses this value on first mount. When the period prop changes (e.g., after clicking a preset button), these state values won't update to reflect the new period. This causes the custom input fields to display stale values that don't match the currently active period, confusing users about which time range is actually selected.
There was a problem hiding this comment.
Claude finished @ericallam's task in 56s —— View job
Fixed custom duration state sync issue
- Read the current implementation
- Add useEffect to sync customValue/customUnit with period prop changes
- Commit and push the fix
Added a useEffect hook that syncs customValue and customUnit state when the period prop changes. This ensures the custom input fields display the correct values after selecting a preset time period or when the period changes externally.
Changes: apps/webapp/app/components/runs/v3/SharedFilters.tsx
- Added
useEffectimport - Added effect to update custom duration state when
periodprop changes
|
Add useEffect to update customValue and customUnit when the period prop changes, fixing stale values in the custom input fields after selecting a preset time period. Co-authored-by: Eric Allam <ericallam@users.noreply.github.com>
PR Review: Custom Time Intervals for Run List FiltersSummaryThis PR adds the ability for users to specify custom time intervals (e.g., 90 minutes) in the run list filters, instead of being limited to preset values. The implementation adds a numeric input with a unit dropdown that integrates with the existing Code Quality and Best PracticesStrengths:
Suggestions:
Potential Bugs or Issues
Performance ConsiderationsThe implementation is lightweight and shouldn't introduce any performance concerns:
One minor optimization: Security ConcernsNo security issues identified. The input is:
Test CoverageThere are no tests for this component. The Recommended test cases to add:
Additional Observations
VerdictThis is a well-implemented feature that cleanly extends existing functionality. The code follows the patterns established in the codebase. Recommended before merge:
🤖 Generated with Claude Code |
|
@claude its working but it's pretty ugly. please make sure you are using existing components that make sense and also match o |
|
Claude finished @ericallam's task in 1m 13s —— View job Improving custom time interval UI styling
Updated the custom duration input to use the existing styled primitives:
These changes ensure the custom duration input matches the app's design system aesthetic. Commit: 97ecf38 View job | |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
apps/webapp/app/components/runs/v3/SharedFilters.tsx (3)
344-356: Consider using zod for validation.The inline validation works, but the coding guidelines specify using zod for validation in the webapp. Consider creating a zod schema for custom duration validation to align with project conventions.
As per coding guidelines: "Use zod for validation in packages/core and apps/webapp"
💡 Example zod schema
import { z } from "zod"; const customDurationSchema = z.object({ value: z.number().int().positive().max(99999), // or appropriate max unit: z.enum(["m", "h", "d"]) });
344-356: Consider edge case handling for custom duration input.The validation allows any positive number, but doesn't handle some edge cases:
- No maximum value constraint (users could enter extremely large numbers)
- The number input allows decimals, but
parseIntsilently truncates them- No user feedback for invalid input beyond disabling the Apply button
Consider adding max value validation and potentially showing error messages for better UX.
393-433: Consider improving accessibility for custom inputs.The number input and select elements lack explicit aria-labels or associated label elements, which could impact screen reader users. Consider adding aria-label attributes for better accessibility.
♿ Accessibility improvement suggestion
<input type="number" min="1" placeholder="e.g. 90" + aria-label="Custom duration value" value={customValue} ... /> <select value={customUnit} onChange={(e) => setCustomUnit(e.target.value)} + aria-label="Custom duration unit" className="..." >
📜 Review details
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
📒 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
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
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
envexport ofenv.server.tsinstead of directly accessingprocess.envin 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/corein 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
Files:
apps/webapp/app/components/runs/v3/SharedFilters.tsx
**/*.{js,ts,jsx,tsx,json,md,css,scss}
📄 CodeRabbit inference engine (AGENTS.md)
Format code using Prettier
Files:
apps/webapp/app/components/runs/v3/SharedFilters.tsx
🧠 Learnings (6)
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Limit task duration using the `maxDuration` property (in seconds)
Applied to files:
apps/webapp/app/components/runs/v3/SharedFilters.tsx
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Use `useRun`, `useRealtimeRun` and other SWR/realtime hooks from `trigger.dev/react-hooks` for data fetching
Applied to files:
apps/webapp/app/components/runs/v3/SharedFilters.tsx
📚 Learning: 2025-11-27T16:26:37.432Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-11-27T16:26:37.432Z
Learning: Applies to internal-packages/database/**/*.{ts,tsx} : Use Prisma for database interactions in internal-packages/database with PostgreSQL
Applied to files:
apps/webapp/app/components/runs/v3/SharedFilters.tsx
📚 Learning: 2025-11-27T16:26:37.432Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-11-27T16:26:37.432Z
Learning: Applies to packages/trigger-sdk/**/*.{ts,tsx} : In the Trigger.dev SDK (packages/trigger-sdk), prefer isomorphic code like fetch and ReadableStream instead of Node.js-specific code
Applied to files:
apps/webapp/app/components/runs/v3/SharedFilters.tsx
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Use `trigger.dev/react-hooks` package for realtime subscriptions in React components
Applied to files:
apps/webapp/app/components/runs/v3/SharedFilters.tsx
📚 Learning: 2025-12-18T14:09:10.154Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 2794
File: internal-packages/run-engine/src/engine/systems/debounceSystem.ts:390-397
Timestamp: 2025-12-18T14:09:10.154Z
Learning: In the debounce system (internal-packages/run-engine/src/engine/systems/debounceSystem.ts), millisecond delays are not supported. The minimum debounce delay is 1 second (1s). The parseNaturalLanguageDuration function supports w/d/hr/h/m/s units only.
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). (24)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (7, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (5, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (6, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (1, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (3, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (2, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (6, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (3, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (8, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (8, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (7, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (4, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (4, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (5, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (2, 8)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - npm)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
- GitHub Check: units / packages / 🧪 Unit Tests: Packages (1, 1)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - pnpm)
- GitHub Check: typecheck / typecheck
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
- GitHub Check: claude-review
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (3)
apps/webapp/app/components/runs/v3/SharedFilters.tsx (3)
193-215: LGTM! Well-structured period rendering logic.The enhanced logic appropriately handles presets, parses custom periods with proper singular/plural formatting, and includes sensible fallbacks.
308-312: Good fix for state synchronization.This useEffect correctly addresses the stale value issue mentioned in the commit message, ensuring the custom input fields stay in sync when a preset is selected.
104-111: Add zod validation for the custom period input.The inline validation (
value > 0check) should be replaced with a zod schema. Per the coding guidelines forapps/webapp/**/*.{ts,tsx}, use zod for validation instead of inline checks. Define a schema to validate the period string format before it's passed to the backend.
Replace raw HTML input and select with the existing Input and SimpleSelect primitives to match the app's design system aesthetic. Co-authored-by: Eric Allam <ericallam@users.noreply.github.com>
PR Review: Custom Time Intervals for Run List FiltersThanks for this feature addition! Allowing custom time intervals is a nice UX improvement over being limited to preset values. Here's my feedback: Overall AssessmentThe implementation is clean and follows existing patterns well. The code integrates nicely with the existing Code Quality & Best PracticesStrengths:
Minor Suggestions:
Potential Bugs or Issues
Performance ConsiderationsThe implementation is performant. A few notes:
The IIFE for Security ConcernsNo security concerns identified. The input is:
Test CoverageMissing: There appear to be no tests included with this PR. Consider adding:
UI/UX Feedback
One suggestion: Consider adding aria-label or aria-describedby to the custom duration input for better accessibility. SummaryThis is a solid feature addition. The main recommendations are:
Nice work! 👍 |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
apps/webapp/app/components/runs/v3/SharedFilters.tsx (2)
352-359: Consider adding maximum value validation.While the function validates that the custom duration is positive, there's no upper bound check. Users could input extremely large values (e.g., 999999 days), which might cause performance issues or unexpected behavior in the backend.
Consider adding a reasonable maximum value based on your application's requirements.
🛡️ Proposed enhancement with max validation
const applyCustomDuration = useCallback(() => { const value = parseInt(customValue, 10); - if (isNaN(value) || value <= 0) { + if (isNaN(value) || value <= 0 || value > 365) { return; } const periodString = `${value}${customUnit}`; handlePeriodClick(periodString); }, [customValue, customUnit, handlePeriodClick]);Note: The maximum of 365 is an example; adjust based on your application's needs. You may also want to adjust this maximum based on the selected unit (e.g., 365 days, but 8760 hours).
361-364: Simplify the validation expression.The IIFE pattern
(() => { ... })()is unnecessarily complex for a simple validation check.♻️ Proposed simplification
-const isCustomDurationValid = (() => { - const value = parseInt(customValue, 10); - return !isNaN(value) && value > 0; -})(); +const value = parseInt(customValue, 10); +const isCustomDurationValid = !isNaN(value) && value > 0;Alternatively, if you want to memoize for performance:
-const isCustomDurationValid = (() => { - const value = parseInt(customValue, 10); - return !isNaN(value) && value > 0; -})(); +const isCustomDurationValid = useMemo(() => { + const value = parseInt(customValue, 10); + return !isNaN(value) && value > 0; +}, [customValue]);
📜 Review details
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
📒 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
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
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
envexport ofenv.server.tsinstead of directly accessingprocess.envin 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/corein 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
Files:
apps/webapp/app/components/runs/v3/SharedFilters.tsx
**/*.{js,ts,jsx,tsx,json,md,css,scss}
📄 CodeRabbit inference engine (AGENTS.md)
Format code using Prettier
Files:
apps/webapp/app/components/runs/v3/SharedFilters.tsx
🧠 Learnings (7)
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Limit task duration using the `maxDuration` property (in seconds)
Applied to files:
apps/webapp/app/components/runs/v3/SharedFilters.tsx
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Use `useRun`, `useRealtimeRun` and other SWR/realtime hooks from `trigger.dev/react-hooks` for data fetching
Applied to files:
apps/webapp/app/components/runs/v3/SharedFilters.tsx
📚 Learning: 2025-11-27T16:26:37.432Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-11-27T16:26:37.432Z
Learning: Applies to packages/trigger-sdk/**/*.{ts,tsx} : In the Trigger.dev SDK (packages/trigger-sdk), prefer isomorphic code like fetch and ReadableStream instead of Node.js-specific code
Applied to files:
apps/webapp/app/components/runs/v3/SharedFilters.tsx
📚 Learning: 2025-11-27T16:26:37.432Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-11-27T16:26:37.432Z
Learning: Applies to internal-packages/database/**/*.{ts,tsx} : Use Prisma for database interactions in internal-packages/database with PostgreSQL
Applied to files:
apps/webapp/app/components/runs/v3/SharedFilters.tsx
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Use `trigger.dev/react-hooks` package for realtime subscriptions in React components
Applied to files:
apps/webapp/app/components/runs/v3/SharedFilters.tsx
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `trigger.dev/sdk/v3` for all imports in Trigger.dev tasks
Applied to files:
apps/webapp/app/components/runs/v3/SharedFilters.tsx
📚 Learning: 2025-12-18T14:09:10.154Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 2794
File: internal-packages/run-engine/src/engine/systems/debounceSystem.ts:390-397
Timestamp: 2025-12-18T14:09:10.154Z
Learning: In the debounce system (internal-packages/run-engine/src/engine/systems/debounceSystem.ts), millisecond delays are not supported. The minimum debounce delay is 1 second (1s). The parseNaturalLanguageDuration function supports w/d/hr/h/m/s units only.
Applied to files:
apps/webapp/app/components/runs/v3/SharedFilters.tsx
🧬 Code graph analysis (1)
apps/webapp/app/components/runs/v3/SharedFilters.tsx (3)
apps/webapp/app/components/primitives/Input.tsx (1)
Input(125-125)apps/webapp/app/components/primitives/Select.tsx (3)
Select(112-258)SelectTrigger(270-374)SelectItem(452-501)apps/webapp/app/components/primitives/SimpleSelect.tsx (2)
SelectValue(142-142)SelectContent(136-136)
⏰ 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). (23)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (6, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (6, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (1, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (7, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (7, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (4, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (2, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (8, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (5, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (5, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (3, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (8, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (2, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (3, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (4, 8)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
- GitHub Check: units / packages / 🧪 Unit Tests: Packages (1, 1)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - pnpm)
- GitHub Check: typecheck / typecheck
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - npm)
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (11)
apps/webapp/app/components/runs/v3/SharedFilters.tsx (11)
5-5: LGTM!The new imports are appropriate for the custom duration feature and align with the app's design system primitives.
Also applies to: 9-9, 12-18
106-110: LGTM!The
timeUnitsconstant provides a clean structure for the custom duration UI with proper singular/plural handling.
112-119: LGTM!The parsing logic correctly extracts value and unit from period strings, with proper null handling for invalid formats.
283-292: LGTM!The function properly initializes custom duration state from period strings, with sensible defaults for empty/invalid periods.
201-223: LGTM!The enhanced rendering logic elegantly handles both preset and custom periods, with proper singular/plural formatting and graceful fallbacks.
310-320: LGTM!The custom duration state is properly initialized and synchronized with period prop changes, preventing stale state issues.
322-332: LGTM!Extracting
applyDateRangeimproves code reuse and maintainability.
401-445: LGTM!The custom duration UI is well-structured with proper validation, keyboard navigation (Enter key), and appropriate use of the app's design system primitives. The disabled state on the Apply button ensures invalid input cannot be submitted.
447-448: LGTM!The visual separator and label effectively distinguish the custom duration section from the exact date range section, improving usability.
500-500: LGTM!Using the extracted
applyDateRangecallback improves code maintainability and eliminates duplication.
352-359: No compatibility issues found with parse-duration.The frontend correctly generates period strings in the format
${value}${customUnit}(e.g., "90m", "2h", "7d") using thetimeUnitsarray with values "m", "h", and "d". The backend uses theparse-durationlibrary in multiple services (runsRepository, clickhouseRunsRepository, BulkActionV2, WaitpointListPresenter, BatchListPresenter, and api.v1.deployments) to parse these periods, with proper error handling in place (e.g., in BulkActionV2.server.ts which throws if parsing fails). The format is compatible with parse-duration's standard notation for durations.
Allow users to specify custom time intervals (e.g., 90 minutes) instead of being limited to preset values. Adds a numeric input field with a unit dropdown (minutes/hours/days) that works with the existing parse-duration backend.