Filter runs by queue, machine, version #2277
Conversation
🦋 Changeset detectedLatest commit: b1ef11e The changes in this PR will be included in the next version bump. 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 |
|
Caution Review failedThe pull request is closed. WalkthroughThis update enhances the run filtering system by adding support for three new filter categories: "machines," "queues," and "versions." It extends filtering schemas, URL parameter parsing, and server-side logic to handle these new filters. The frontend UI is updated with new searchable, multi-select dropdown components and applied filter tags for machines, queues, and versions. The runs table includes a new "Queue" column displaying queue names with icons and tooltips indicating queue types. Additional utilities and hooks, such as a new debounced effect hook, support improved filtering interactions. Backend presenters and loaders are added or updated to provide paginated version data and integrate the new filters consistently across the application. Estimated code review effort4 (60–120 minutes) 📜 Recent review detailsConfiguration used: CodeRabbit UI ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (18)
✨ 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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
apps/webapp/app/components/runs/v3/RunFilters.tsx (1)
858-873: Consider adding error handling for the fetch operation.The component handles loading state but doesn't handle potential fetch errors. Consider adding error handling to provide user feedback when the queue fetch fails.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
apps/webapp/app/components/runs/v3/RunFilters.tsx(12 hunks)apps/webapp/app/components/runs/v3/TaskRunsTable.tsx(4 hunks)apps/webapp/app/hooks/useDebounce.ts(2 hunks)apps/webapp/app/presenters/RunFilters.server.ts(3 hunks)apps/webapp/app/presenters/v3/NextRunListPresenter.server.ts(5 hunks)apps/webapp/app/services/runsRepository.server.ts(4 hunks)
🧰 Additional context used
📓 Path-based instructions (5)
apps/webapp/**/*.ts
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .cursor/rules/webapp.mdc
apps/webapp/**/*.{ts,tsx}
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .cursor/rules/webapp.mdc
**/*.{ts,tsx}
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .github/copilot-instructions.md
{packages/core,apps/webapp}/**/*.{ts,tsx}
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .github/copilot-instructions.md
**/*.tsx
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .cursor/rules/writing-tasks.mdc
🧠 Learnings (7)
📓 Common learnings
Learnt from: matt-aitken
PR: triggerdotdev/trigger.dev#2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.105Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-30T13:22:21.528Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use the `runs` and `tasks` APIs from `@trigger.dev/sdk/v3` to subscribe to run updates and implement realtime features.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-30T13:22:21.528Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use the `metadata` API from `@trigger.dev/sdk/v3` to attach, update, and access structured metadata within task runs.
apps/webapp/app/services/runsRepository.server.ts (3)
Learnt from: matt-aitken
PR: triggerdotdev/trigger.dev#2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.105Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-30T13:22:21.528Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use the `runs` and `tasks` APIs from `@trigger.dev/sdk/v3` to subscribe to run updates and implement realtime features.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T13:21:33.994Z
Learning: Applies to internal-packages/database/**/*.{ts,tsx} : We use prisma in internal-packages/database for our database interactions using PostgreSQL
apps/webapp/app/components/runs/v3/TaskRunsTable.tsx (3)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-30T13:22:21.528Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use the `runs` and `tasks` APIs from `@trigger.dev/sdk/v3` to subscribe to run updates and implement realtime features.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-30T13:22:21.528Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Scheduled tasks must use `schedules.task` from `@trigger.dev/sdk/v3` and define a `cron` property for declarative schedules.
Learnt from: matt-aitken
PR: triggerdotdev/trigger.dev#2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.105Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
apps/webapp/app/presenters/v3/NextRunListPresenter.server.ts (4)
Learnt from: matt-aitken
PR: triggerdotdev/trigger.dev#2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.105Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-30T13:22:21.528Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use the `runs` and `tasks` APIs from `@trigger.dev/sdk/v3` to subscribe to run updates and implement realtime features.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-30T13:22:21.528Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them within the `task` function in Trigger.dev task files.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-30T13:22:21.528Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use the `metadata` API from `@trigger.dev/sdk/v3` to attach, update, and access structured metadata within task runs.
apps/webapp/app/presenters/RunFilters.server.ts (2)
Learnt from: matt-aitken
PR: triggerdotdev/trigger.dev#2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.105Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-30T13:22:21.528Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : The `run` function must contain the main logic for each Trigger.dev task.
apps/webapp/app/hooks/useDebounce.ts (2)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-30T13:22:21.528Z
Learning: Applies to **/*.tsx : When using React hooks for realtime updates, use `@trigger.dev/react-hooks` and provide a Public Access Token via context or props.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T13:21:33.994Z
Learning: Applies to **/*.{ts,tsx} : No default exports, use function declarations
apps/webapp/app/components/runs/v3/RunFilters.tsx (11)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-30T13:22:21.528Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use the `runs` and `tasks` APIs from `@trigger.dev/sdk/v3` to subscribe to run updates and implement realtime features.
Learnt from: matt-aitken
PR: triggerdotdev/trigger.dev#2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.105Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-30T13:22:21.528Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use the `metadata` API from `@trigger.dev/sdk/v3` to attach, update, and access structured metadata within task runs.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-30T13:22:21.528Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Scheduled tasks must use `schedules.task` from `@trigger.dev/sdk/v3` and define a `cron` property for declarative schedules.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-30T13:22:21.528Z
Learning: Applies to **/*.tsx : When using React hooks for realtime updates, use `@trigger.dev/react-hooks` and provide a Public Access Token via context or props.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-30T13:22:21.528Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : The `run` function must contain the main logic for each Trigger.dev task.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-30T13:22:21.528Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : You MUST `export` every task, including subtasks, in Trigger.dev task files.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-30T13:22:21.528Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Lifecycle hooks (`init`, `cleanup`, `onStart`, `onSuccess`, `onFailure`, `handleError`) must be defined as properties of the `task` function in Trigger.dev task files.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-30T13:22:21.528Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them within the `task` function in Trigger.dev task files.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-30T13:22:21.528Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : When triggering a task from inside another task, use the task instance's `trigger`, `batchTrigger`, `triggerAndWait`, `batchTriggerAndWait`, `batch.trigger`, `batch.triggerAndWait`, `batch.triggerByTask`, or `batch.triggerByTaskAndWait` methods.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-30T13:22:21.528Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Schema tasks must use `schemaTask` from `@trigger.dev/sdk/v3` and validate payloads using a schema (e.g., Zod).
🧬 Code Graph Analysis (1)
apps/webapp/app/presenters/RunFilters.server.ts (1)
apps/webapp/app/services/runsRepository.server.ts (1)
ParsedRunFilters(48-51)
⏰ 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). (25)
- GitHub Check: units / packages / 📊 Merge Reports
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (3, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (5, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (6, 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 (8, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (1, 10)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (7, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (10, 10)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (7, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (6, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (9, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (2, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (3, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (4, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (5, 10)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - npm)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - pnpm)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
- GitHub Check: typecheck / typecheck
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (27)
apps/webapp/app/hooks/useDebounce.ts (2)
1-1: LGTM: Import statement properly updatedThe addition of
useEffectto the import is correct for the new hook implementation.
23-43: LGTM: Well-implemented debounced effect hookThe
useDebounceEffecthook follows React best practices:
- Uses
useRefto store the latest function version, preventing stale closures- Effect dependencies are correctly limited to
valueanddelayonly- Proper cleanup with
clearTimeoutto prevent memory leaks- Clear documentation explaining the purpose and behavior
This implementation correctly addresses the common React gotcha of function references changing on every render.
apps/webapp/app/presenters/RunFilters.server.ts (3)
6-6: LGTM: Correct import of ParsedRunFilters typeThe import aligns with the type definition in the runsRepository service.
8-10: LGTM: Well-defined type alias and return typeThe
FiltersFromRequesttype alias clearly defines the contract, and the explicit return type improves type safety and documentation.
35-35: LGTM: Consistent queue filter integrationThe
queuesfield is properly destructured from the parsed filters and included in the returned object, maintaining consistency with other filter fields.Also applies to: 53-53
apps/webapp/app/components/runs/v3/TaskRunsTable.tsx (4)
55-55: LGTM: Appropriate icon importThe
TaskIconSmallimport is correctly added to support the new queue column display.
80-80: LGTM: Clean up of unused destructuringGood cleanup removing the unused
selectedItemsdestructuring while maintaining the necessary hooks.
206-206: LGTM: Queue column header additionThe queue column header is properly placed and follows the existing table structure.
385-400: LGTM: Well-implemented queue cell with type-specific iconsThe queue cell implementation is excellent:
- Uses appropriate icons for different queue types (TaskIconSmall for task queues, RectangleStackIcon for custom queues)
- Provides informative tooltips explaining the queue type
- Consistent styling with proper color coding (blue for task queues, purple for custom)
- Clear visual hierarchy with icon and text layout
The conditional rendering based on
run.queue.typealigns with the queue metadata structure added in the presenter.apps/webapp/app/services/runsRepository.server.ts (4)
39-39: LGTM: Correct schema extension for queue filteringThe
queuesfield is properly added as an optional string array, consistent with other filter fields in the schema.
48-51: LGTM: Well-defined ParsedRunFilters typeThe exported type correctly extends
RunListInputFilterswith pagination-related properties, providing a clear contract for the filtering system.
178-178: LGTM: Queue field added to Prisma selectThe
queuefield is correctly added to the Prisma select clause to ensure queue data is retrieved for display in the UI.
363-365: LGTM: Proper queue filtering implementationThe queue filtering logic is correctly implemented:
- Uses the appropriate ClickHouse IN operator for multiple queue values
- Follows the same pattern as other array-based filters
- Properly checks for non-empty array before applying the filter
The implementation is consistent with other filter conditions in the function.
apps/webapp/app/presenters/v3/NextRunListPresenter.server.ts (5)
32-32: LGTM: Correct type extension for queue filteringThe
queuesfield is properly added as an optional string array to theRunListOptionstype, maintaining consistency with other filter fields.
68-68: LGTM: Method signature updated consistentlyThe
queuesparameter is correctly added to the method signature, maintaining the established pattern for filter parameters.
94-94: LGTM: Queue filter included in hasFilters logicThe queue filter is properly included in the
hasFiltersdetection logic, ensuring the UI correctly shows when filters are applied.
178-178: LGTM: Queue filter passed to repositoryThe
queuesparameter is correctly passed to therunsRepository.listRunscall, ensuring the filtering is applied at the data layer.
238-241: LGTM: Sensible queue metadata transformationThe queue metadata transformation is well-implemented:
- Removes the "task/" prefix from queue names for cleaner display
- Determines queue type based on the "task/" prefix
- Provides structured data that aligns with the UI requirements
This transformation makes the queue information more user-friendly while preserving the underlying queue classification.
apps/webapp/app/components/runs/v3/RunFilters.tsx (9)
1-63: Import additions look good.All new imports are properly structured and necessary for the queue filtering feature implementation.
113-113: Schema addition for queues filter is correct.The
queuesfield follows the established pattern usingStringOrStringArraypreprocessor, maintaining consistency with other filter fields.
147-148: Filter title and icon configuration is properly implemented.The "Queues" title and RectangleStackIcon are appropriate choices that maintain consistency with the existing filter UI patterns.
Also applies to: 181-182
217-220: URL parameter extraction for queues is correctly implemented.The code properly handles multiple queue values and filters empty strings, maintaining consistency with other filter parameters.
254-255: Queue filter detection properly integrated.Adding
queuesto the hasFilters check ensures the clear filters button appears when queue filters are active.
283-283: Queue filter type properly added to filter menu.The entry maintains consistency with other filter types and is logically positioned in the menu.
363-364: Menu integration for queues filter is correct.The switch case properly renders the QueuesDropdown component with appropriate props.
334-334: Applied queues filter properly integrated.The component is correctly positioned in the applied filters list.
968-998: AppliedQueuesFilter component is well implemented.The component properly displays queue filters with cleaned names (removing "task/" prefix) and integrates correctly with the filter system.
matt-aitken
force-pushed
the
queue-filtering
branch
from
15e6dc0 to
8b3289d
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (10)
apps/webapp/app/assets/icons/MachineIcon.tsx(1 hunks)apps/webapp/app/components/MachineLabelCombo.tsx(1 hunks)apps/webapp/app/components/runs/v3/RunFilters.tsx(13 hunks)apps/webapp/app/components/runs/v3/TaskRunsTable.tsx(4 hunks)apps/webapp/app/hooks/useDebounce.ts(2 hunks)apps/webapp/app/presenters/RunFilters.server.ts(3 hunks)apps/webapp/app/presenters/v3/NextRunListPresenter.server.ts(6 hunks)apps/webapp/app/services/platform.v3.server.ts(0 hunks)apps/webapp/app/services/runsRepository.server.ts(5 hunks)apps/webapp/app/utils/cn.ts(1 hunks)
💤 Files with no reviewable changes (1)
- apps/webapp/app/services/platform.v3.server.ts
✅ Files skipped from review due to trivial changes (1)
- apps/webapp/app/assets/icons/MachineIcon.tsx
🚧 Files skipped from review as they are similar to previous changes (5)
- apps/webapp/app/presenters/RunFilters.server.ts
- apps/webapp/app/hooks/useDebounce.ts
- apps/webapp/app/components/runs/v3/TaskRunsTable.tsx
- apps/webapp/app/presenters/v3/NextRunListPresenter.server.ts
- apps/webapp/app/services/runsRepository.server.ts
🧰 Additional context used
📓 Path-based instructions (5)
apps/webapp/**/*.{ts,tsx}
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .cursor/rules/webapp.mdc
**/*.tsx
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .cursor/rules/writing-tasks.mdc
**/*.{ts,tsx}
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .github/copilot-instructions.md
{packages/core,apps/webapp}/**/*.{ts,tsx}
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .github/copilot-instructions.md
apps/webapp/**/*.ts
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .cursor/rules/webapp.mdc
🧠 Learnings (3)
📓 Common learnings
Learnt from: matt-aitken
PR: triggerdotdev/trigger.dev#2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.105Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-30T13:22:21.528Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use the `runs` and `tasks` APIs from `@trigger.dev/sdk/v3` to subscribe to run updates and implement realtime features.
apps/webapp/app/components/MachineLabelCombo.tsx (5)
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#1608
File: apps/webapp/app/v3/services/triggerTask.server.ts:418-418
Timestamp: 2025-01-13T18:31:48.160Z
Learning: The `MachinePresetName` schema is used to validate machine preset values in the trigger.dev codebase, ensuring type safety and validation of machine preset options.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T13:21:33.994Z
Learning: Applies to **/*.{ts,tsx} : Avoid enums
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T13:21:33.994Z
Learning: Applies to **/*.{ts,tsx} : No default exports, use function declarations
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-06-30T13:21:59.438Z
Learning: Applies to apps/webapp/app/**/*.test.{ts,tsx} : Tests should only import classes and functions from files matching `app/**/*.ts` of the webapp, and those files should not use environment variables; everything should be passed through as options instead.
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2150
File: apps/supervisor/src/workloadManager/docker.ts:115-115
Timestamp: 2025-06-04T16:02:22.957Z
Learning: In the Trigger.dev codebase, the supervisor component uses DOCKER_ENFORCE_MACHINE_PRESETS while the docker provider component uses ENFORCE_MACHINE_PRESETS. These are separate components with separate environment variable configurations for the same logical concept of enforcing machine presets.
apps/webapp/app/components/runs/v3/RunFilters.tsx (11)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-30T13:22:21.528Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use the `runs` and `tasks` APIs from `@trigger.dev/sdk/v3` to subscribe to run updates and implement realtime features.
Learnt from: matt-aitken
PR: triggerdotdev/trigger.dev#2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.105Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-30T13:22:21.528Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use the `metadata` API from `@trigger.dev/sdk/v3` to attach, update, and access structured metadata within task runs.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-30T13:22:21.528Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Schema tasks must use `schemaTask` from `@trigger.dev/sdk/v3` and validate payloads using a schema (e.g., Zod).
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-30T13:22:21.528Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Scheduled tasks must use `schedules.task` from `@trigger.dev/sdk/v3` and define a `cron` property for declarative schedules.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-30T13:22:21.528Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them within the `task` function in Trigger.dev task files.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-30T13:22:21.528Z
Learning: Applies to **/*.tsx : When using React hooks for realtime updates, use `@trigger.dev/react-hooks` and provide a Public Access Token via context or props.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-30T13:22:21.528Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : The `run` function must contain the main logic for each Trigger.dev task.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-30T13:22:21.528Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : You MUST `export` every task, including subtasks, in Trigger.dev task files.
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#1608
File: apps/webapp/app/v3/services/triggerTask.server.ts:418-418
Timestamp: 2025-01-13T18:31:48.160Z
Learning: The `MachinePresetName` schema is used to validate machine preset values in the trigger.dev codebase, ensuring type safety and validation of machine preset options.
Learnt from: matt-aitken
PR: triggerdotdev/trigger.dev#2264
File: apps/webapp/app/utils/searchParams.ts:16-18
Timestamp: 2025-07-12T18:00:06.142Z
Learning: The `objectToSearchParams` function in `apps/webapp/app/utils/searchParams.ts` is used to generate URL parameters from objects and is separate from code that parses incoming search parameters. Changes to this function only affect places where it's used to create URLs, not places that parse search parameters from external sources.
⏰ 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). (25)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (9, 10)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (8, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (4, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (7, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (6, 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 (7, 10)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (2, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (10, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (8, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (6, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (5, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (4, 10)
- GitHub Check: units / packages / 🧪 Unit Tests: Packages (1, 1)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (1, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (3, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (2, 10)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - pnpm)
- GitHub Check: typecheck / typecheck
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - npm)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (4)
apps/webapp/app/components/MachineLabelCombo.tsx (1)
1-6: LGTM!The import change and new
machinesexport are correctly implemented to support the machine filtering functionality.apps/webapp/app/components/runs/v3/RunFilters.tsx (3)
313-327: LGTM!The filter types are properly configured with appropriate icons and titles for the new queue and machine filters.
870-1004: Well-implemented queue filtering with proper debouncing.The QueuesDropdown component correctly:
- Uses organization/project/environment context
- Implements debounced search to avoid excessive API calls
- Distinguishes between task and custom queues with appropriate icons
- Handles selected values properly in the filtered results
1038-1092: Clean implementation of machine filtering.The MachinesDropdown component properly uses the imported machines list and implements efficient filtering with matchSorter.
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (2)
apps/webapp/app/presenters/v3/VersionListPresenter.server.ts (1)
23-23: Consider more robust query validationThe current logic treats any non-empty query string as having filters, but it doesn't validate the query content.
Consider adding more specific validation:
- const hasFilters = query !== undefined && query.length > 0; + const hasFilters = query !== undefined && query.trim().length > 0;apps/webapp/app/routes/resources.orgs.$organizationSlug.projects.$projectParam.env.$envParam.versions.ts (1)
40-40: Remove redundant explicit parameter namingThe parameter name is the same as the property name, making the explicit naming redundant.
- environment: environment, + environment,
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
apps/webapp/app/components/runs/v3/RunFilters.tsx(14 hunks)apps/webapp/app/presenters/v3/VersionListPresenter.server.ts(1 hunks)apps/webapp/app/routes/resources.orgs.$organizationSlug.projects.$projectParam.env.$envParam.versions.ts(1 hunks)apps/webapp/app/services/runsRepository.server.ts(5 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- apps/webapp/app/services/runsRepository.server.ts
- apps/webapp/app/components/runs/v3/RunFilters.tsx
🧰 Additional context used
📓 Path-based instructions (4)
apps/webapp/**/*.ts
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .cursor/rules/webapp.mdc
apps/webapp/**/*.{ts,tsx}
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .cursor/rules/webapp.mdc
**/*.{ts,tsx}
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .github/copilot-instructions.md
{packages/core,apps/webapp}/**/*.{ts,tsx}
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .github/copilot-instructions.md
🧠 Learnings (2)
📓 Common learnings
Learnt from: matt-aitken
PR: triggerdotdev/trigger.dev#2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.105Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-30T13:22:21.528Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use the `runs` and `tasks` APIs from `@trigger.dev/sdk/v3` to subscribe to run updates and implement realtime features.
apps/webapp/app/presenters/v3/VersionListPresenter.server.ts (1)
Learnt from: matt-aitken
PR: triggerdotdev/trigger.dev#2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.105Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
🧬 Code Graph Analysis (2)
apps/webapp/app/presenters/v3/VersionListPresenter.server.ts (1)
packages/core/src/v3/isomorphic/consts.ts (1)
CURRENT_DEPLOYMENT_LABEL(1-1)
apps/webapp/app/routes/resources.orgs.$organizationSlug.projects.$projectParam.env.$envParam.versions.ts (5)
apps/webapp/app/services/session.server.ts (1)
requireUserId(25-35)apps/webapp/app/utils/pathBuilder.ts (1)
EnvironmentParamSchema(26-28)apps/webapp/app/models/project.server.ts (1)
findProjectBySlug(109-120)apps/webapp/app/models/runtimeEnvironment.server.ts (1)
findEnvironmentBySlug(116-145)apps/webapp/app/presenters/v3/VersionListPresenter.server.ts (1)
VersionListPresenter(8-69)
⏰ 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). (25)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (6, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (5, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (7, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (10, 10)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (4, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (8, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (9, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (6, 10)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (3, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (8, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (3, 10)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (2, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (5, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (4, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (7, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (1, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (2, 10)
- 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 - pnpm)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - npm)
- GitHub Check: typecheck / typecheck
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (7)
apps/webapp/app/presenters/v3/VersionListPresenter.server.ts (3)
3-3: LGTM: Correct import from subpath exportThe import from
@trigger.dev/core/v3/isomorphicfollows the coding guidelines by using a subpath export instead of the root path.
11-14: LGTM: Proper pagination bounds enforcementThe constructor correctly caps the
perPageparameter at the maximum allowed value, preventing potential performance issues from excessive page sizes.
40-58: LGTM: Proper current version detection logicThe logic correctly identifies the current deployment version only for non-DEVELOPMENT environments, which aligns with the business logic where DEVELOPMENT environments don't have deployment promotions.
apps/webapp/app/routes/resources.orgs.$organizationSlug.projects.$projectParam.env.$envParam.versions.ts (4)
9-12: LGTM: Proper input validation schemaThe schema correctly validates query parameters with appropriate defaults and constraints. The
z.coerce.number().min(1)ensures valid pagination values.
15-16: LGTM: Proper authentication and parameter validationThe loader correctly enforces authentication and validates route parameters using the established patterns.
21-27: LGTM: Proper resource validation with security checkThe project lookup includes proper user authorization by checking organization membership through
findProjectBySlug.
29-35: LGTM: Environment access controlThe environment lookup properly handles access control for different environment types, allowing appropriate access based on user permissions.
...app/routes/resources.orgs.$organizationSlug.projects.$projectParam.env.$envParam.versions.ts
Outdated
Show resolved
Hide resolved
matt-aitken
force-pushed
the
queue-filtering
branch
from
3bccaa9 to
85e29c1
Compare
matt-aitken
changed the title
matt-aitken
force-pushed
the
queue-filtering
branch
from
8d837fb to
2d48b3c
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
references/hello-world/src/trigger/sdk.tsis excluded by!references/**
📒 Files selected for processing (8)
.changeset/two-eagles-report.md(1 hunks)apps/webapp/app/components/BulkActionFilterSummary.tsx(1 hunks)apps/webapp/app/presenters/v3/ApiRunListPresenter.server.ts(3 hunks)apps/webapp/app/routes/resources.orgs.$organizationSlug.projects.$projectParam.env.$envParam.versions.ts(1 hunks)apps/webapp/app/utils/cn.ts(1 hunks)packages/core/src/v3/apiClient/index.ts(2 hunks)packages/core/src/v3/apiClient/types.ts(2 hunks)packages/core/src/v3/schemas/queues.ts(2 hunks)
✅ Files skipped from review due to trivial changes (1)
- packages/core/src/v3/schemas/queues.ts
🚧 Files skipped from review as they are similar to previous changes (2)
- apps/webapp/app/utils/cn.ts
- apps/webapp/app/routes/resources.orgs.$organizationSlug.projects.$projectParam.env.$envParam.versions.ts
🧰 Additional context used
📓 Path-based instructions (3)
**/*.{ts,tsx}
📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)
**/*.{ts,tsx}: Always prefer using isomorphic code like fetch, ReadableStream, etc. instead of Node.js specific code
For TypeScript, we usually use types over interfaces
Avoid enums
No default exports, use function declarations
Files:
apps/webapp/app/components/BulkActionFilterSummary.tsxpackages/core/src/v3/apiClient/types.tspackages/core/src/v3/apiClient/index.tsapps/webapp/app/presenters/v3/ApiRunListPresenter.server.ts
{packages/core,apps/webapp}/**/*.{ts,tsx}
📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)
We use zod a lot in packages/core and in the webapp
Files:
apps/webapp/app/components/BulkActionFilterSummary.tsxpackages/core/src/v3/apiClient/types.tspackages/core/src/v3/apiClient/index.tsapps/webapp/app/presenters/v3/ApiRunListPresenter.server.ts
apps/webapp/**/*.{ts,tsx}
📄 CodeRabbit Inference Engine (.cursor/rules/webapp.mdc)
apps/webapp/**/*.{ts,tsx}: In the webapp, all environment variables must be accessed through theenvexport ofenv.server.ts, instead of directly accessingprocess.env.
When importing from@trigger.dev/corein the webapp, never import from the root@trigger.dev/corepath; always use one of the subpath exports as defined in the package's package.json.
Files:
apps/webapp/app/components/BulkActionFilterSummary.tsxapps/webapp/app/presenters/v3/ApiRunListPresenter.server.ts
🧠 Learnings (5)
📓 Common learnings
Learnt from: matt-aitken
PR: triggerdotdev/trigger.dev#2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.133Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : When using Realtime features, use the `runs.subscribeToRun`, `runs.subscribeToRunsWithTag`, and `runs.subscribeToBatch` APIs as shown.
.changeset/two-eagles-report.md (10)
Learnt from: matt-aitken
PR: #2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.133Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using Realtime features, use the runs.subscribeToRun, runs.subscribeToRunsWithTag, and runs.subscribeToBatch APIs as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them as shown in the examples for Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : You MUST use @trigger.dev/sdk/v3 when writing Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : The run function contains your task logic in Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When implementing scheduled (cron) tasks, use schedules.task from @trigger.dev/sdk/v3 and follow the shown patterns.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : ALWAYS generate Trigger.dev tasks using the task function from @trigger.dev/sdk/v3 and export them as shown in the correct pattern.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When triggering a task from backend code, use tasks.trigger, tasks.batchTrigger, or tasks.triggerAndPoll as shown in the examples.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When implementing schema tasks, use schemaTask from @trigger.dev/sdk/v3 and validate payloads as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to trigger.config.ts : Build extensions such as additionalFiles, additionalPackages, aptGet, emitDecoratorMetadata, prismaExtension, syncEnvVars, puppeteer, ffmpeg, and esbuildPlugin must be configured in trigger.config.ts as shown.
packages/core/src/v3/apiClient/types.ts (1)
Learnt from: nicktrn
PR: #1608
File: apps/webapp/app/v3/services/triggerTask.server.ts:418-418
Timestamp: 2025-01-13T18:31:48.160Z
Learning: The MachinePresetName schema is used to validate machine preset values in the trigger.dev codebase, ensuring type safety and validation of machine preset options.
packages/core/src/v3/apiClient/index.ts (1)
Learnt from: matt-aitken
PR: #2264
File: apps/webapp/app/utils/searchParams.ts:16-18
Timestamp: 2025-07-12T18:00:06.163Z
Learning: The objectToSearchParams function in apps/webapp/app/utils/searchParams.ts is used to generate URL parameters from objects and is separate from code that parses incoming search parameters. Changes to this function only affect places where it's used to create URLs, not places that parse search parameters from external sources.
apps/webapp/app/presenters/v3/ApiRunListPresenter.server.ts (6)
Learnt from: matt-aitken
PR: #2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.133Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/v3/presenters/**/*.server.ts : Favor the use of 'presenters' to move complex loader code into a class, as seen in app/v3/presenters/**/*.server.ts.
Learnt from: nicktrn
PR: #1608
File: apps/webapp/app/v3/services/triggerTask.server.ts:418-418
Timestamp: 2025-01-13T18:31:48.160Z
Learning: The MachinePresetName schema is used to validate machine preset values in the trigger.dev codebase, ensuring type safety and validation of machine preset options.
Learnt from: nicktrn
PR: #2150
File: apps/supervisor/src/workloadManager/docker.ts:115-115
Timestamp: 2025-06-04T16:02:22.957Z
Learning: In the Trigger.dev codebase, the supervisor component uses DOCKER_ENFORCE_MACHINE_PRESETS while the docker provider component uses ENFORCE_MACHINE_PRESETS. These are separate components with separate environment variable configurations for the same logical concept of enforcing machine presets.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using Realtime features, use the runs.subscribeToRun, runs.subscribeToRunsWithTag, and runs.subscribeToBatch APIs as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : The run function contains your task logic in Trigger.dev tasks.
🧬 Code Graph Analysis (2)
packages/core/src/v3/apiClient/types.ts (1)
packages/core/src/v3/schemas/common.ts (2)
MachinePresetName(97-105)MachinePresetName(107-107)
apps/webapp/app/presenters/v3/ApiRunListPresenter.server.ts (1)
packages/core/src/v3/schemas/common.ts (2)
MachinePresetName(97-105)MachinePresetName(107-107)
⏰ 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). (25)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (5, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (6, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (4, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (7, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (8, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (3, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (8, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (10, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (9, 10)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (2, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (7, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (3, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (4, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (1, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (6, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (2, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (5, 10)
- GitHub Check: units / packages / 🧪 Unit Tests: Packages (1, 1)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
- GitHub Check: typecheck / typecheck
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - npm)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - pnpm)
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (11)
.changeset/two-eagles-report.md (1)
1-6: LGTM!The changeset properly documents the addition of queue and machine filtering capabilities to the SDK's runs.list functionality.
apps/webapp/app/components/BulkActionFilterSummary.tsx (2)
204-216: LGTM!The queue filter handling correctly removes the "task/" prefix for display purposes, which aligns with the API client's
queueNameFromQueueTypeNamefunction that adds this prefix.
217-229: LGTM!The machine filter implementation follows the established pattern and correctly displays machine preset values without transformation.
packages/core/src/v3/apiClient/types.ts (2)
1-6: LGTM!The imports are correctly added to support the new queue and machine filtering parameters.
40-61: Excellent documentation and type safety.The queue parameter includes comprehensive JSDoc examples showing both single and array usage patterns. The flexible typing allowing either single values or arrays is consistent with other parameters in the interface.
packages/core/src/v3/apiClient/index.ts (3)
24-24: LGTM!The QueueTypeName import is correctly added to support the new queue filtering functionality.
1174-1180: Well-implemented helper function.The
queueNameFromQueueTypeNamefunction correctly handles the queue type formatting by prefixing "task/" for task queues while using the name directly for other queue types. This aligns with the display logic inBulkActionFilterSummary.tsxthat strips this prefix.
1154-1168: LGTM!The queue and machine filtering logic is well-implemented:
- Queue filtering uses the helper function to format queue names consistently
- Machine filtering handles string/array conversion appropriately
- Both follow the established patterns for other filters in this function
apps/webapp/app/presenters/v3/ApiRunListPresenter.server.ts (3)
4-4: LGTM!The MachinePresetName import is correctly added to support machine filtering validation.
110-115: LGTM!The queue filter implementation follows the established pattern of simple string splitting, which is appropriate for queue names.
245-251: LGTM!The presenter method correctly checks for the new filter parameters and assigns them to the options object for downstream processing.
matt-aitken
force-pushed
the
queue-filtering
branch
from
9d8cd36 to
b1ef11e
Compare
Added new run filters to the dashboard
This is part 1 of 2 in a stack made with GitButler: