Filter runs by queue #2277
Filter runs by queue #2277
Conversation
|
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. ✨ 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.
| size: [ | ||
| { | ||
| size: [ | ||
| "0", | ||
| "0.5", | ||
| "1", | ||
| "1.5", | ||
| "2", | ||
| "2.5", | ||
| "3", | ||
| "3.5", | ||
| "4", | ||
| "5", | ||
| "6", | ||
| "7", | ||
| "8", | ||
| "9", | ||
| "10", | ||
| "11", | ||
| "12", | ||
| "14", | ||
| "16", | ||
| "20", | ||
| "24", | ||
| "28", | ||
| "32", | ||
| "36", | ||
| "40", | ||
| "44", | ||
| "48", | ||
| "52", | ||
| "56", | ||
| "60", | ||
| "64", | ||
| "72", | ||
| "80", | ||
| "96", | ||
| "auto", | ||
| "px", | ||
| "0.5", | ||
| "1", | ||
| "1.5", | ||
| "2", | ||
| "2.5", | ||
| "3", | ||
| "3.5", | ||
| "4", | ||
| "5", | ||
| "6", | ||
| "7", | ||
| "8", | ||
| "9", | ||
| "10", | ||
| "11", | ||
| "12", | ||
| "14", | ||
| "16", | ||
| "20", | ||
| "24", | ||
| "28", | ||
| "32", | ||
| "36", | ||
| "40", | ||
| "44", | ||
| "48", | ||
| "52", | ||
| "56", | ||
| "60", | ||
| "64", | ||
| "72", | ||
| "80", | ||
| "96", | ||
| "auto", | ||
| "px", | ||
| "full", | ||
| "min", | ||
| "max", | ||
| "fit", | ||
| ], | ||
| }, | ||
| ], |
There was a problem hiding this comment.
Remove duplicate size values in the configuration.
The size values from lines 67-101 are exact duplicates of lines 31-65. This duplication serves no purpose in the Tailwind merge configuration.
Apply this diff to fix the duplication:
size: [
{
size: [
"0",
"0.5",
"1",
"1.5",
"2",
"2.5",
"3",
"3.5",
"4",
"5",
"6",
"7",
"8",
"9",
"10",
"11",
"12",
"14",
"16",
"20",
"24",
"28",
"32",
"36",
"40",
"44",
"48",
"52",
"56",
"60",
"64",
"72",
"80",
"96",
"auto",
"px",
- "0.5",
- "1",
- "1.5",
- "2",
- "2.5",
- "3",
- "3.5",
- "4",
- "5",
- "6",
- "7",
- "8",
- "9",
- "10",
- "11",
- "12",
- "14",
- "16",
- "20",
- "24",
- "28",
- "32",
- "36",
- "40",
- "44",
- "48",
- "52",
- "56",
- "60",
- "64",
- "72",
- "80",
- "96",
- "auto",
- "px",
"full",
"min",
"max",
"fit",
],
},
],📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| size: [ | |
| { | |
| size: [ | |
| "0", | |
| "0.5", | |
| "1", | |
| "1.5", | |
| "2", | |
| "2.5", | |
| "3", | |
| "3.5", | |
| "4", | |
| "5", | |
| "6", | |
| "7", | |
| "8", | |
| "9", | |
| "10", | |
| "11", | |
| "12", | |
| "14", | |
| "16", | |
| "20", | |
| "24", | |
| "28", | |
| "32", | |
| "36", | |
| "40", | |
| "44", | |
| "48", | |
| "52", | |
| "56", | |
| "60", | |
| "64", | |
| "72", | |
| "80", | |
| "96", | |
| "auto", | |
| "px", | |
| "0.5", | |
| "1", | |
| "1.5", | |
| "2", | |
| "2.5", | |
| "3", | |
| "3.5", | |
| "4", | |
| "5", | |
| "6", | |
| "7", | |
| "8", | |
| "9", | |
| "10", | |
| "11", | |
| "12", | |
| "14", | |
| "16", | |
| "20", | |
| "24", | |
| "28", | |
| "32", | |
| "36", | |
| "40", | |
| "44", | |
| "48", | |
| "52", | |
| "56", | |
| "60", | |
| "64", | |
| "72", | |
| "80", | |
| "96", | |
| "auto", | |
| "px", | |
| "full", | |
| "min", | |
| "max", | |
| "fit", | |
| ], | |
| }, | |
| ], | |
| size: [ | |
| { | |
| size: [ | |
| "0", | |
| "0.5", | |
| "1", | |
| "1.5", | |
| "2", | |
| "2.5", | |
| "3", | |
| "3.5", | |
| "4", | |
| "5", | |
| "6", | |
| "7", | |
| "8", | |
| "9", | |
| "10", | |
| "11", | |
| "12", | |
| "14", | |
| "16", | |
| "20", | |
| "24", | |
| "28", | |
| "32", | |
| "36", | |
| "40", | |
| "44", | |
| "48", | |
| "52", | |
| "56", | |
| "60", | |
| "64", | |
| "72", | |
| "80", | |
| "96", | |
| "auto", | |
| "px", | |
| "full", | |
| "min", | |
| "max", | |
| "fit", | |
| ], | |
| }, | |
| ], |
🤖 Prompt for AI Agents
In apps/webapp/app/utils/cn.ts between lines 28 and 108, the size array contains
duplicate values repeated from lines 31-65 and 67-101. Remove the second set of
duplicate size values (lines 67-101) so that each size value appears only once
in the configuration array to avoid redundancy.
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.
| const versions = await this._replica.backgroundWorker.findMany({ | ||
| select: { | ||
| version: true, | ||
| }, | ||
| where: { | ||
| runtimeEnvironmentId: environment.id, | ||
| }, | ||
| orderBy: { | ||
| createdAt: "desc", | ||
| }, | ||
| take: this.perPage, | ||
| }); |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify the database query efficiency
The query fetches versions from backgroundWorker table without using the query parameter for filtering. This might not be the intended behavior if the query is meant to filter versions.
🏁 Script executed:
#!/bin/bash
# Check if there are other places where version filtering by query is implemented
rg -A 5 -B 5 "backgroundWorker\.findMany" --type tsLength of output: 3770
Apply query filtering to the backgroundWorker query
The query parameter is declared and hasFilters is computed, but it’s never applied to the Prisma query—so search inputs won’t narrow the version list.
• File: apps/webapp/app/presenters/v3/VersionListPresenter.server.ts
- In the
findManycall’swhereclause, include the version filter whenhasFiltersis true:where: { runtimeEnvironmentId: environment.id, ...(hasFilters ? { version: { contains: query!, mode: 'insensitive' } } : {}), },
• Example diff:
where: {
runtimeEnvironmentId: environment.id,
+ ...(hasFilters
+ ? { version: { contains: query!, mode: 'insensitive' } }
+ : {}),
},🤖 Prompt for AI Agents
In apps/webapp/app/presenters/v3/VersionListPresenter.server.ts between lines 25
and 36, the Prisma query to find versions does not apply the version filter
based on the query parameter and hasFilters flag. Modify the where clause of the
findMany call to conditionally include a version filter using contains with
case-insensitive mode when hasFilters is true, merging it with the existing
runtimeEnvironmentId filter.
| versions: versions.map((version) => ({ | ||
| version: version.version, | ||
| isCurrent: version.version === currentVersion, | ||
| })), |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider potential duplicate versions in results
The current query doesn't use DISTINCT on the version field, which could return duplicate versions if multiple background workers exist for the same version.
Consider adding distinct selection:
const versions = await this._replica.backgroundWorker.findMany({
select: {
version: true,
},
+ distinct: ['version'],
where: {
runtimeEnvironmentId: environment.id,
},
orderBy: {
createdAt: "desc",
},
take: this.perPage,
});📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| versions: versions.map((version) => ({ | |
| version: version.version, | |
| isCurrent: version.version === currentVersion, | |
| })), | |
| const versions = await this._replica.backgroundWorker.findMany({ | |
| select: { | |
| version: true, | |
| }, | |
| distinct: ['version'], | |
| where: { | |
| runtimeEnvironmentId: environment.id, | |
| }, | |
| orderBy: { | |
| createdAt: "desc", | |
| }, | |
| take: this.perPage, | |
| }); |
🤖 Prompt for AI Agents
In apps/webapp/app/presenters/v3/VersionListPresenter.server.ts around lines 62
to 65, the mapping over versions may include duplicates because the query does
not enforce distinct version values. Modify the database query that fetches the
versions to include a DISTINCT clause on the version field to ensure only unique
versions are returned before mapping them.
| if (!result.success) { | ||
| return { | ||
| versions: [], | ||
| hasFilters: Boolean(query?.trim()), | ||
| }; | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Inconsistent hasFilters logic with presenter
The fallback logic uses Boolean(query?.trim()) while the presenter uses query !== undefined && query.length > 0. This inconsistency could lead to different hasFilters values.
Use consistent logic:
return {
versions: [],
- hasFilters: Boolean(query?.trim()),
+ hasFilters: query !== undefined && query.length > 0,
};Or better yet, extract this logic to a shared utility function to ensure consistency.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| if (!result.success) { | |
| return { | |
| versions: [], | |
| hasFilters: Boolean(query?.trim()), | |
| }; | |
| } | |
| if (!result.success) { | |
| return { | |
| versions: [], | |
| hasFilters: query !== undefined && query.length > 0, | |
| }; | |
| } |
🤖 Prompt for AI Agents
In
apps/webapp/app/routes/resources.orgs.$organizationSlug.projects.$projectParam.env.$envParam.versions.ts
around lines 44 to 49, the hasFilters logic in the fallback uses
Boolean(query?.trim()) which is inconsistent with the presenter logic query !==
undefined && query.length > 0. To fix this, unify the hasFilters condition by
using the same check as the presenter or extract the hasFilters determination
into a shared utility function and use it in both places to ensure consistent
behavior.
No description provided.