AI run filtering #2285
AI run filtering #2285
Conversation
|
WalkthroughThis set of changes introduces an AI-powered filtering feature for task runs in the web application. A new Estimated code review effort4 (~90 minutes) 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (6)
💤 Files with no reviewable changes (1)
✅ Files skipped from review due to trivial changes (2)
🚧 Files skipped from review as they are similar to previous changes (2)
🧰 Additional context used📓 Path-based instructions (3)**/*.{ts,tsx}📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)
Files:
{packages/core,apps/webapp}/**/*.{ts,tsx}📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)
Files:
apps/webapp/**/*.{ts,tsx}📄 CodeRabbit Inference Engine (.cursor/rules/webapp.mdc)
Files:
🧠 Learnings (2)📓 Common learningsapps/webapp/evals/aiRunFilter.eval.ts (19)Learnt from: matt-aitken Learnt from: CR Learnt from: CR Learnt from: CR Learnt from: CR Learnt from: CR Learnt from: nicktrn Learnt from: CR Learnt from: CR Learnt from: CR Learnt from: CR Learnt from: CR Learnt from: CR Learnt from: CR Learnt from: CR Learnt from: CR Learnt from: CR Learnt from: CR Learnt from: CR ⏰ 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)
✨ 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 (
|
matt-aitken
force-pushed
the
ai-run-filtering
branch
from
01ffc88 to
f952f1e
Compare
| }), | ||
| }, | ||
| maxSteps: 5, | ||
| system: `You are an AI assistant that converts natural language descriptions into structured filter parameters for a task run filtering system. |
There was a problem hiding this comment.
An idea about this: what do you think about also supporting modification of the existing filters?
We could pass in the current filters value to the prompt and ask the model to detect whether the user intents to create new filters or modify the existing ones. E.g., a user prompt along the lines of "include runs from last week" should keep the existing filters and only adjust the date range. While something like "failed runs in the last month" would disregard current filters.
|
Awesome feature 🔥 |
matt-aitken
force-pushed
the
ai-run-filtering
branch
from
f952f1e to
05a2cd9
Compare
matt-aitken
force-pushed
the
queue-filtering
branch
from
9d8cd36 to
b1ef11e
Compare
matt-aitken
force-pushed
the
ai-run-filtering
branch
from
05a2cd9 to
80562a9
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 12
♻️ Duplicate comments (1)
apps/webapp/app/v3/services/aiRunFilterService.server.ts (1)
144-144: Consider supporting modification of existing filtersAs suggested in a previous review, the service could support modifying existing filters by accepting and passing the current filter values to the AI prompt. This would enable queries like "include runs from last week" to preserve existing filters while only adjusting the date range.
🧹 Nitpick comments (1)
apps/webapp/evals/aiRunFilter.eval.ts (1)
242-242: Extract magic string as a constantThe userId "123456" is used as a magic string. Consider extracting it as a constant for better maintainability.
+const TEST_USER_ID = "123456"; + evalite("AI Run Filter", { // ... existing code ... task: async (input) => { const service = new AIRunFilterService({ queryTags, queryVersions, queryQueues, queryTasks, }); - const result = await service.call(input, "123456"); + const result = await service.call(input, TEST_USER_ID); return JSON.stringify(result); },
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (17)
apps/webapp/app/components/primitives/Input.tsx(2 hunks)apps/webapp/app/components/runs/v3/AIFilterInput.tsx(1 hunks)apps/webapp/app/components/runs/v3/RunFilters.tsx(6 hunks)apps/webapp/app/hooks/useSearchParam.ts(2 hunks)apps/webapp/app/presenters/v3/ApiRunListPresenter.server.ts(1 hunks)apps/webapp/app/presenters/v3/QueueListPresenter.server.ts(1 hunks)apps/webapp/app/presenters/v3/VersionListPresenter.server.ts(2 hunks)apps/webapp/app/routes/resources.orgs.$organizationSlug.projects.$projectParam.env.$envParam.runs.ai-filter.tsx(1 hunks)apps/webapp/app/routes/storybook.input-fields/route.tsx(3 hunks)apps/webapp/app/routes/storybook.search-fields/route.tsx(5 hunks)apps/webapp/app/services/runsRepository.server.ts(1 hunks)apps/webapp/app/tailwind.css(1 hunks)apps/webapp/app/utils/cn.ts(1 hunks)apps/webapp/app/v3/services/aiRunFilterService.server.ts(1 hunks)apps/webapp/evals/aiRunFilter.eval.ts(1 hunks)apps/webapp/package.json(6 hunks)packages/core/src/v3/apiClient/index.ts(1 hunks)
🧰 Additional context used
📓 Path-based instructions (4)
**/*.{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/presenters/v3/QueueListPresenter.server.tsapps/webapp/app/services/runsRepository.server.tspackages/core/src/v3/apiClient/index.tsapps/webapp/app/presenters/v3/ApiRunListPresenter.server.tsapps/webapp/app/utils/cn.tsapps/webapp/app/routes/storybook.input-fields/route.tsxapps/webapp/app/routes/storybook.search-fields/route.tsxapps/webapp/app/components/primitives/Input.tsxapps/webapp/app/presenters/v3/VersionListPresenter.server.tsapps/webapp/app/components/runs/v3/RunFilters.tsxapps/webapp/app/hooks/useSearchParam.tsapps/webapp/app/v3/services/aiRunFilterService.server.tsapps/webapp/evals/aiRunFilter.eval.tsapps/webapp/app/components/runs/v3/AIFilterInput.tsxapps/webapp/app/routes/resources.orgs.$organizationSlug.projects.$projectParam.env.$envParam.runs.ai-filter.tsx
{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/presenters/v3/QueueListPresenter.server.tsapps/webapp/app/services/runsRepository.server.tspackages/core/src/v3/apiClient/index.tsapps/webapp/app/presenters/v3/ApiRunListPresenter.server.tsapps/webapp/app/utils/cn.tsapps/webapp/app/routes/storybook.input-fields/route.tsxapps/webapp/app/routes/storybook.search-fields/route.tsxapps/webapp/app/components/primitives/Input.tsxapps/webapp/app/presenters/v3/VersionListPresenter.server.tsapps/webapp/app/components/runs/v3/RunFilters.tsxapps/webapp/app/hooks/useSearchParam.tsapps/webapp/app/v3/services/aiRunFilterService.server.tsapps/webapp/evals/aiRunFilter.eval.tsapps/webapp/app/components/runs/v3/AIFilterInput.tsxapps/webapp/app/routes/resources.orgs.$organizationSlug.projects.$projectParam.env.$envParam.runs.ai-filter.tsx
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/presenters/v3/QueueListPresenter.server.tsapps/webapp/app/services/runsRepository.server.tsapps/webapp/app/presenters/v3/ApiRunListPresenter.server.tsapps/webapp/app/utils/cn.tsapps/webapp/app/routes/storybook.input-fields/route.tsxapps/webapp/app/routes/storybook.search-fields/route.tsxapps/webapp/app/components/primitives/Input.tsxapps/webapp/app/presenters/v3/VersionListPresenter.server.tsapps/webapp/app/components/runs/v3/RunFilters.tsxapps/webapp/app/hooks/useSearchParam.tsapps/webapp/app/v3/services/aiRunFilterService.server.tsapps/webapp/evals/aiRunFilter.eval.tsapps/webapp/app/components/runs/v3/AIFilterInput.tsxapps/webapp/app/routes/resources.orgs.$organizationSlug.projects.$projectParam.env.$envParam.runs.ai-filter.tsx
apps/webapp/app/services/**/*.server.ts
📄 CodeRabbit Inference Engine (.cursor/rules/webapp.mdc)
For testable services, separate service logic and configuration, as exemplified by
realtimeClient.server.ts(service) andrealtimeClientGlobal.server.ts(configuration).
Files:
apps/webapp/app/services/runsRepository.server.ts
🧠 Learnings (15)
📓 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.
apps/webapp/app/presenters/v3/QueueListPresenter.server.ts (13)
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: 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} : Tasks must be exported, even subtasks in the same file.
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} : 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-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: Before generating any code for Trigger.dev tasks, verify: (1) Are you importing from @trigger.dev/sdk/v3? (2) Have you exported every task? (3) Have you generated any deprecated code 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} : 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} : 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} : 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//*.{ts,tsx,js,jsx} : The run function contains your task logic in Trigger.dev tasks.
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 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} : When using Realtime features, use the runs.subscribeToRun, runs.subscribeToRunsWithTag, and runs.subscribeToBatch APIs as shown.
apps/webapp/app/services/runsRepository.server.ts (3)
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: ericallam
PR: #2175
File: apps/webapp/app/services/environmentMetricsRepository.server.ts:202-207
Timestamp: 2025-06-14T08:07:46.625Z
Learning: In apps/webapp/app/services/environmentMetricsRepository.server.ts, the ClickHouse methods (getTaskActivity, getCurrentRunningStats, getAverageDurations) intentionally do not filter by the tasks parameter at the ClickHouse level, even though the tasks parameter is accepted by the public methods. This is done on purpose as there is not much benefit from adding that filtering at the ClickHouse layer.
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.
packages/core/src/v3/apiClient/index.ts (2)
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.
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.
apps/webapp/app/presenters/v3/ApiRunListPresenter.server.ts (2)
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.
apps/webapp/app/utils/cn.ts (1)
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.
apps/webapp/app/routes/storybook.input-fields/route.tsx (1)
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/**/*.{ts,tsx} : When importing from @trigger.dev/core in the webapp, never import from the root @trigger.dev/core path; always use one of the subpath exports as defined in the package's package.json.
apps/webapp/app/routes/storybook.search-fields/route.tsx (1)
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/**/*.{ts,tsx} : When importing from @trigger.dev/core in the webapp, never import from the root @trigger.dev/core path; always use one of the subpath exports as defined in the package's package.json.
apps/webapp/package.json (6)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.458Z
Learning: Applies to {packages/core,apps/webapp}/**/*.{ts,tsx} : We use zod a lot in packages/core and in the webapp
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/**/*.{ts,tsx} : When importing from @trigger.dev/core in the webapp, never import from the root @trigger.dev/core path; always use one of the subpath exports as defined in the package's package.json.
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/**/*.test.{ts,tsx} : Tests in the webapp should only import classes and functions from files matching app/**/*.ts, and those files should not use environment variables directly; all configuration should be passed as options.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.458Z
Learning: Applies to **/*.test.{ts,tsx} : Our tests are all vitest
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} : ALWAYS generate Trigger.dev tasks using the task function from @trigger.dev/sdk/v3 and export them as shown in the correct pattern.
apps/webapp/app/presenters/v3/VersionListPresenter.server.ts (5)
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: 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/**/*.{ts,tsx} : In the webapp, all environment variables must be accessed through the env export of env.server.ts, instead of directly accessing process.env.
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/**/*.test.{ts,tsx} : Test files in the webapp should not import env.server.ts, either directly or indirectly. Tests should only import classes and functions from files matching app/**/*.ts of the webapp, and those files should not use environment variables directly; everything should be passed through as options instead.
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/**/*.{ts,tsx} : When importing from @trigger.dev/core in the webapp, never import from the root @trigger.dev/core path; always use one of the subpath exports as defined in the package's package.json.
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/**/*.test.{ts,tsx} : Tests in the webapp should only import classes and functions from files matching app/**/*.ts, and those files should not use environment variables directly; all configuration should be passed as options.
apps/webapp/app/components/runs/v3/RunFilters.tsx (9)
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 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//*.{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} : Tasks must be exported, even subtasks in the same file.
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 metadata in tasks, use the metadata API as shown, and only inside run functions or task lifecycle hooks.
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} : 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} : 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-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : The run function contains your task logic in Trigger.dev tasks.
apps/webapp/app/hooks/useSearchParam.ts (2)
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.
Learnt from: matt-aitken
PR: #1313
File: apps/webapp/app/hooks/useSearchParam.ts:21-21
Timestamp: 2024-09-17T16:37:27.060Z
Learning: When using URLSearchParams.set followed by .toString(), values are automatically URL-encoded. Manually encoding these values can lead to double encoding issues.
apps/webapp/app/v3/services/aiRunFilterService.server.ts (4)
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} : 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} : When triggering a task from backend code, use tasks.trigger, tasks.batchTrigger, or tasks.triggerAndPoll as shown in the examples.
apps/webapp/evals/aiRunFilter.eval.ts (4)
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/**/*.test.{ts,tsx} : Tests in the webapp should only import classes and functions from files matching app/**/*.ts, and those files should not use environment variables directly; all configuration should be passed as options.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.458Z
Learning: Applies to **/*.test.{ts,tsx} : Our tests are all vitest
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/**/*.test.{ts,tsx} : Test files in the webapp should not import env.server.ts, either directly or indirectly. Tests should only import classes and functions from files matching app/**/*.ts of the webapp, and those files should not use environment variables directly; everything should be passed through as options instead.
apps/webapp/app/routes/resources.orgs.$organizationSlug.projects.$projectParam.env.$envParam.runs.ai-filter.tsx (3)
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} : 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 using metadata in tasks, use the metadata API as shown, and only inside run functions or task lifecycle hooks.
🧬 Code Graph Analysis (3)
apps/webapp/app/routes/storybook.input-fields/route.tsx (2)
apps/webapp/app/components/primitives/ShortcutKey.tsx (1)
ShortcutKey(38-55)apps/webapp/app/components/environments/EnvironmentLabel.tsx (1)
EnvironmentLabel(70-126)
apps/webapp/app/components/primitives/Input.tsx (3)
apps/webapp/app/components/primitives/ShortcutKey.tsx (1)
variants(14-19)apps/webapp/app/components/primitives/Icon.tsx (1)
RenderIcon(4-4)apps/webapp/app/utils/cn.ts (1)
cn(112-114)
apps/webapp/app/components/runs/v3/AIFilterInput.tsx (10)
apps/webapp/app/components/runs/v3/RunFilters.tsx (2)
TaskRunListSearchFilters(114-183)TaskRunListSearchFilters(185-185)apps/webapp/app/hooks/useProject.tsx (1)
useProject(20-24)apps/webapp/app/hooks/useEnvironment.tsx (1)
useEnvironment(19-23)apps/webapp/app/utils/searchParams.ts (1)
objectToSearchParams(4-25)apps/webapp/app/components/primitives/Input.tsx (1)
Input(107-107)apps/webapp/app/utils/cn.ts (1)
cn(112-114)apps/webapp/app/assets/icons/AISparkleIcon.tsx (1)
AISparkleIcon(1-31)apps/webapp/app/components/primitives/Spinner.tsx (1)
Spinner(8-62)apps/webapp/app/components/primitives/ShortcutKey.tsx (1)
ShortcutKey(38-55)apps/webapp/app/components/primitives/Popover.tsx (3)
Popover(205-205)PopoverTrigger(212-212)PopoverContent(207-207)
🪛 Biome (1.9.4)
apps/webapp/app/components/runs/v3/RunFilters.tsx
[error] 399-399: Avoid using unnecessary Fragment.
A fragment is redundant if it contains only one child, or if it is the child of a html element, and is not a keyed fragment.
Unsafe fix: Remove the Fragment
(lint/complexity/noUselessFragments)
⏰ 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 (8, 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 / webapp / 🧪 Unit Tests: Webapp (7, 10)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (5, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (3, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (2, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (8, 10)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (10, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (6, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (1, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (9, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (5, 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 (2, 10)
- GitHub Check: units / packages / 🧪 Unit Tests: Packages (1, 1)
- 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 - pnpm)
- GitHub Check: typecheck / typecheck
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - npm)
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (11)
apps/webapp/app/presenters/v3/VersionListPresenter.server.ts (1)
2-2: LGTM: Good type refinement.The change from
AuthenticatedEnvironmentto a more specificPick<RuntimeEnvironment, "id" | "type">improves the interface by explicitly declaring only the required properties. This reduces coupling and makes the dependencies clearer.Also applies to: 20-20
apps/webapp/app/presenters/v3/QueueListPresenter.server.ts (1)
1-5: LGTM: Clean import consolidation.Good consolidation of related type imports from
@trigger.dev/database. This improves maintainability by grouping related imports together.apps/webapp/app/routes/storybook.search-fields/route.tsx (1)
8-8: LGTM! Clean refactoring of Input component API.The changes correctly replace the deprecated
shortcutprop with the newaccessoryprop pattern using theShortcutKeycomponent. The implementation is consistent across all Input instances and maintains the same keyboard shortcut functionality.Also applies to: 22-24, 35-37, 57-59, 68-70, 79-81
apps/webapp/app/presenters/v3/ApiRunListPresenter.server.ts (1)
113-118: LGTM! Proper implementation of new queue and machine filters.The new filters follow established patterns in the codebase:
- Queue filter correctly splits comma-separated values
- Machine filter includes proper validation against
MachinePresetNameenum with appropriate error handling- Both filters are properly integrated into the options passed to
NextRunListPresenterAlso applies to: 119-145, 254-260
apps/webapp/app/tailwind.css (1)
75-98: LGTM! Well-implemented gradient glow variant for smaller elements.The new
.animated-gradient-glow-smallclass provides a more subtle, intense glow effect suitable for smaller UI components. The implementation correctly follows the same pattern as the existing glow class while using appropriate values for smaller elements (reduced inset, lighter blur, higher opacity).apps/webapp/app/routes/storybook.input-fields/route.tsx (1)
4-4: LGTM! Consistent Input component refactoring with proper variant matching.The changes correctly implement the new
accessoryprop pattern, replacing the deprecatedshortcutprop. TheShortcutKeyvariant is appropriately matched to the Input size (medium variant for large inputs, small variant for others), and the pattern is consistently applied across all Input instances regardless of their icon type.Also applies to: 30-30, 37-37, 44-44, 51-51, 60-60, 67-67, 74-74, 81-81, 88-88, 95-95
apps/webapp/package.json (1)
26-27: LGTM! Dependencies properly added for AI filtering feature.The new dependencies and eval script align well with the AI-powered filtering functionality:
- AI SDK dependencies for OpenAI integration
- Radix UI portal for UI components (likely for the error popover)
- Evaluation tooling for testing the AI filter service
Also applies to: 35-35, 89-89, 126-126, 252-252, 263-263
apps/webapp/app/routes/resources.orgs.$organizationSlug.projects.$projectParam.env.$envParam.runs.ai-filter.tsx (1)
64-133: Well-structured query function implementations.The query functions are properly abstracted with:
- Consistent error handling in queues query
- Proper filtering by environment/project context
- Clean data transformation for the AI service
apps/webapp/app/components/primitives/Input.tsx (1)
49-55: Excellent refactoring to improve component flexibility.The replacement of the
shortcutprop with a genericaccessoryprop is a great architectural improvement that:
- Allows any React node to be rendered as an accessory
- Maintains backward compatibility through proper styling
- Adds flexibility with the new
containerClassNamepropAlso applies to: 62-67, 100-100
apps/webapp/app/components/runs/v3/AIFilterInput.tsx (1)
160-202: Well-implemented error popover with proper timeout management.The ErrorPopover component correctly:
- Manages timeout with proper cleanup
- Uses accessible Radix UI components
- Provides good UX with automatic dismissal
apps/webapp/app/components/runs/v3/RunFilters.tsx (1)
115-182: Excellent schema documentation for AI parsing.The detailed
.describe()annotations provide clear guidance for the AI service with:
- Specific format examples (e.g., "20250718.1" for versions)
- ID prefixes (e.g., "run_", "batch_", "sched_")
- Valid enum values for statuses and machines
- Clear explanations of filter purposes
This will significantly improve the AI's ability to parse natural language queries accurately.
...tes/resources.orgs.$organizationSlug.projects.$projectParam.env.$envParam.runs.ai-filter.tsx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
apps/webapp/app/components/runs/v3/AIFilterInput.tsx (1)
152-153: Consider using number type instead of NodeJS.Timeout for browser compatibility.In browser environments,
setTimeoutreturns anumber, notNodeJS.Timeout. Consider usingnumber | undefinedfor better type accuracy.- const timeout = useRef<NodeJS.Timeout | undefined>(); + const timeout = useRef<number | undefined>();
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
apps/webapp/app/components/runs/v3/AIFilterInput.tsx(1 hunks)
🧰 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/runs/v3/AIFilterInput.tsx
{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/runs/v3/AIFilterInput.tsx
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/runs/v3/AIFilterInput.tsx
🧠 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.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.
apps/webapp/app/components/runs/v3/AIFilterInput.tsx (3)
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 logging in tasks, use the logger API (logger.debug, logger.log, logger.info, logger.warn, logger.error) 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} : NEVER generate deprecated code patterns using client.defineJob and related deprecated APIs, as shown in the prohibited code block.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.458Z
Learning: Applies to **/*.{ts,tsx} : Always prefer using isomorphic code like fetch, ReadableStream, etc. instead of Node.js specific code
⏰ 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 / webapp / 🧪 Unit Tests: Webapp (7, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (8, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (5, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (10, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (9, 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 (2, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (3, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (6, 10)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (8, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (4, 10)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (5, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (6, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (3, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (2, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (4, 8)
- GitHub Check: units / packages / 🧪 Unit Tests: Packages (1, 1)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-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 (13)
apps/webapp/app/components/runs/v3/AIFilterInput.tsx (13)
1-14: Import organization looks good.The imports are well-organized, necessary for the functionality, and follow appropriate patterns for a Remix React component with UI primitives and animations.
16-26: Well-structured type definition using discriminated unions.The
AIFilterResulttype effectively uses discriminated unions with thesuccessfield as the discriminant, providing type safety for accessing state-specific properties.
28-36: Component setup follows React best practices.The state management is minimal and appropriate, with proper use of custom hooks for context and Remix patterns for form handling.
38-54: Well-implemented effect for handling successful AI filter responses.The effect properly handles the success flow with appropriate state cleanup, URL navigation, and UX improvements like refocusing the input.
59-63: Form setup follows Remix patterns correctly.The action URL is properly constructed using context values and follows the expected RESTful pattern for the AI filter endpoint.
65-85: Well-implemented Framer Motion animations.The width expansion animation and glow effect are smoothly implemented with appropriate timing parameters and proper AnimatePresence handling.
87-101: Input component is well-configured.The controlled component pattern, accessibility features, and custom styling for different states are properly implemented.
102-110: Keyboard handling is properly implemented.The Enter key handling includes appropriate guard conditions and uses
requestSubmit()for proper form validation and event firing.
111-116: Thoughtful focus handling for better UX.The blur logic maintains visual focus state during loading operations, preventing jarring visual changes during form submission.
117-135: Well-implemented state-based accessory display.The icon and accessory logic provides clear visual feedback with smooth transitions between different states (loading, text present, empty).
143-151: Well-designed component signature for ErrorPopover.The props interface is clean with appropriate types, and the 10-second default duration provides a good balance between readability and user experience.
155-171: Well-implemented timeout management with proper cleanup.The effect correctly handles timeout cleanup and prevents memory leaks. The logic ensures proper auto-close behavior for error states.
173-185: Excellent popover implementation with proper accessibility and styling.The use of Radix components ensures accessibility, while the CSS custom properties for width matching and error theming provide polished UX.
This is part 2 of 2 in a stack made with GitButler: