Usage billing alerts #2323
Usage billing alerts #2323
Conversation
|
WalkthroughThis change set introduces a new billing alerts feature for managed cloud organizations, including a dedicated settings page and supporting backend logic. The navigation menu is updated to include a "Billing alerts" item. A new route for billing alerts settings is added, featuring form-based configuration with validation and dynamic input handling. Supporting service functions for retrieving and updating billing alert settings are implemented. The code also introduces organization-level controls for enabling or disabling runs, with associated API endpoints and UI logic to conditionally display environment controls based on run status. Minor updates include dependency version bumps, import path corrections, style enhancements for input fields, and adjustments to environment pause/resume behavior based on run enablement status. Estimated code review effort🎯 4 (Complex) | ⏱️ ~40 minutes
Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (3)
✅ Files skipped from review due to trivial changes (3)
⏰ 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🧪 Generate unit tests
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: 5
🧹 Nitpick comments (8)
apps/webapp/app/components/primitives/Input.tsx (1)
10-10: Limit spinner-removal styles to number inputsCurrent selector disables WebKit/Firefox spin buttons for all inputs rendered with this component.
That could unintentionally hide increment controls on date/time or custom numeric widgets later.Consider scoping the rule to
type="number"only:- [&::-webkit-outer-spin-button]:appearance-none [&::-webkit-inner-spin-button]:appearance-none [&::-webkit-outer-spin-button]:m-0 [&::-webkit-inner-spin-button]:m-0 [&]:[-moz-appearance:textfield] + [&[type=number]::-webkit-outer-spin-button]:appearance-none \ + [&[type=number]::-webkit-inner-spin-button]:appearance-none \ + [&[type=number]::-webkit-outer-spin-button]:m-0 \ + [&[type=number]::-webkit-inner-spin-button]:m-0 \ + [&[type=number]]:[-moz-appearance:textfield]This keeps the UI change targeted while preserving default behaviour for other input types.
apps/webapp/app/presenters/v3/EnvironmentQueuePresenter.server.ts (1)
27-38: Consider optimizing database query.The organization lookup is implemented correctly with proper error handling. However, consider if this query could be combined with existing data fetching to reduce database round trips.
The current approach is functional but adds an extra database query. If the environment object already includes organization data or if there's a way to fetch this in a single query with the existing data, that would be more efficient.
apps/webapp/app/routes/admin.api.v1.orgs.$organizationId.runs.enable.ts (3)
24-25: Fix grammatical error in comment.-/** - * It will enabled/disable runs - */ +/** + * It will enable/disable runs + */
54-65: Consider checking organization existence before update.The organization existence check happens after the update operation. Consider fetching the organization first to validate it exists before attempting the update.
+ // Check if organization exists first + const existingOrg = await prisma.organization.findUnique({ + where: { id: organizationId } + }); + + if (!existingOrg) { + return json({ error: "Organization not found" }, { status: 404 }); + } const organization = await prisma.organization.update({ where: { id: organizationId, }, data: { runsEnabled: body.data.enable, }, }); - if (!organization) { - return json({ error: "Organization not found" }, { status: 404 }); - }
80-89: Consider wrapping operations in a transaction.The multi-step operation (updating organization + pausing/resuming environments) could benefit from transaction wrapping to ensure consistency if any environment operation fails.
+ await prisma.$transaction(async (tx) => { + const organization = await tx.organization.update({ + where: { id: organizationId }, + data: { runsEnabled: body.data.enable }, + }); const environments = await prisma.runtimeEnvironment.findMany({ // ... existing query }); const pauseEnvironmentService = new PauseEnvironmentService(); for (const environment of environments) { if (body.data.enable) { await pauseEnvironmentService.call({ ...environment, organization }, "resumed"); } else { await pauseEnvironmentService.call({ ...environment, organization }, "paused"); } } + });apps/webapp/app/v3/services/pauseEnvironment.server.ts (1)
30-37: UsefindUniqueinstead offindFirstfor organization lookupSince you're querying by the primary key (
id),findUniquewould be more semantically correct and performant thanfindFirst.- const org = await this._prisma.organization.findFirst({ - where: { - id: environment.organizationId, - }, + const org = await this._prisma.organization.findUnique({ + where: { + id: environment.organizationId, + },apps/webapp/app/routes/_app.orgs.$organizationSlug.settings.billing-alerts/route.tsx (2)
154-155: Address the TODO commentThe TODO comment indicates missing TypeScript types for the form submission.
Would you like me to help generate the proper TypeScript types for the
lastSubmissionparameter?
207-215: Improve negative number handlingSetting the value to empty string when negative could be confusing. Consider preventing negative values at input level or showing validation errors instead.
onChange={(e) => { - const numberValue = Number(e.target.value); - if (numberValue < 0) { - setDollarAmount(""); - return; - } setDollarAmount(e.target.value); }}The
min={0}attribute already prevents negative values in most browsers, and the schema validation will catch any edge cases.
📜 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 (13)
apps/webapp/app/components/billing/UpgradePrompt.tsx(1 hunks)apps/webapp/app/components/navigation/OrganizationSettingsSideMenu.tsx(3 hunks)apps/webapp/app/components/primitives/Input.tsx(1 hunks)apps/webapp/app/presenters/v3/EnvironmentQueuePresenter.server.ts(2 hunks)apps/webapp/app/routes/_app.orgs.$organizationSlug.projects.$projectParam.env.$envParam.queues/route.tsx(1 hunks)apps/webapp/app/routes/_app.orgs.$organizationSlug.settings.billing-alerts/route.tsx(1 hunks)apps/webapp/app/routes/_app.orgs.$organizationSlug.settings.billing/route.tsx(1 hunks)apps/webapp/app/routes/admin.api.v1.orgs.$organizationId.runs.enable.ts(1 hunks)apps/webapp/app/routes/resources.orgs.$organizationSlug.select-plan.tsx(1 hunks)apps/webapp/app/services/platform.v3.server.ts(2 hunks)apps/webapp/app/utils/pathBuilder.ts(1 hunks)apps/webapp/app/v3/services/pauseEnvironment.server.ts(1 hunks)apps/webapp/package.json(2 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/routes/_app.orgs.$organizationSlug.settings.billing/route.tsxapps/webapp/app/utils/pathBuilder.tsapps/webapp/app/routes/_app.orgs.$organizationSlug.projects.$projectParam.env.$envParam.queues/route.tsxapps/webapp/app/components/billing/UpgradePrompt.tsxapps/webapp/app/routes/resources.orgs.$organizationSlug.select-plan.tsxapps/webapp/app/presenters/v3/EnvironmentQueuePresenter.server.tsapps/webapp/app/components/primitives/Input.tsxapps/webapp/app/components/navigation/OrganizationSettingsSideMenu.tsxapps/webapp/app/v3/services/pauseEnvironment.server.tsapps/webapp/app/services/platform.v3.server.tsapps/webapp/app/routes/admin.api.v1.orgs.$organizationId.runs.enable.tsapps/webapp/app/routes/_app.orgs.$organizationSlug.settings.billing-alerts/route.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/routes/_app.orgs.$organizationSlug.settings.billing/route.tsxapps/webapp/app/utils/pathBuilder.tsapps/webapp/app/routes/_app.orgs.$organizationSlug.projects.$projectParam.env.$envParam.queues/route.tsxapps/webapp/app/components/billing/UpgradePrompt.tsxapps/webapp/app/routes/resources.orgs.$organizationSlug.select-plan.tsxapps/webapp/app/presenters/v3/EnvironmentQueuePresenter.server.tsapps/webapp/app/components/primitives/Input.tsxapps/webapp/app/components/navigation/OrganizationSettingsSideMenu.tsxapps/webapp/app/v3/services/pauseEnvironment.server.tsapps/webapp/app/services/platform.v3.server.tsapps/webapp/app/routes/admin.api.v1.orgs.$organizationId.runs.enable.tsapps/webapp/app/routes/_app.orgs.$organizationSlug.settings.billing-alerts/route.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/routes/_app.orgs.$organizationSlug.settings.billing/route.tsxapps/webapp/app/utils/pathBuilder.tsapps/webapp/app/routes/_app.orgs.$organizationSlug.projects.$projectParam.env.$envParam.queues/route.tsxapps/webapp/app/components/billing/UpgradePrompt.tsxapps/webapp/app/routes/resources.orgs.$organizationSlug.select-plan.tsxapps/webapp/app/presenters/v3/EnvironmentQueuePresenter.server.tsapps/webapp/app/components/primitives/Input.tsxapps/webapp/app/components/navigation/OrganizationSettingsSideMenu.tsxapps/webapp/app/v3/services/pauseEnvironment.server.tsapps/webapp/app/services/platform.v3.server.tsapps/webapp/app/routes/admin.api.v1.orgs.$organizationId.runs.enable.tsapps/webapp/app/routes/_app.orgs.$organizationSlug.settings.billing-alerts/route.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/platform.v3.server.ts
🧠 Learnings (7)
apps/webapp/app/routes/_app.orgs.$organizationSlug.settings.billing/route.tsx (10)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.180Z
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/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
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:25.014Z
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:25.014Z
Learning: Applies to trigger.config.ts : The trigger.config.ts file must use defineConfig from @trigger.dev/sdk/v3 and follow the configuration structure shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
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:25.014Z
Learning: Applies to trigger.config.ts : Global lifecycle hooks, telemetry, runtime, machine settings, log level, max duration, and build configuration must be set in trigger.config.ts as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
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:25.014Z
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:25.014Z
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:25.014Z
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/_app.orgs.$organizationSlug.projects.$projectParam.env.$envParam.queues/route.tsx (1)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.180Z
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.
apps/webapp/package.json (14)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.180Z
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/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
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:25.014Z
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:25.014Z
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.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
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:25.014Z
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.468Z
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/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
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:25.014Z
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:25.014Z
Learning: Applies to trigger.config.ts : The trigger.config.ts file must use defineConfig from @trigger.dev/sdk/v3 and follow the configuration structure shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
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:25.014Z
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:25.014Z
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:25.014Z
Learning: Applies to trigger.config.ts : Global lifecycle hooks, telemetry, runtime, machine settings, log level, max duration, and build configuration must be set in trigger.config.ts as shown.
apps/webapp/app/routes/resources.orgs.$organizationSlug.select-plan.tsx (13)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.180Z
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/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
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:25.014Z
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:25.014Z
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:25.014Z
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:25.014Z
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:25.014Z
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:25.014Z
Learning: Applies to trigger.config.ts : The trigger.config.ts file must use defineConfig from @trigger.dev/sdk/v3 and follow the configuration structure shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
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: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
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:25.014Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using Realtime features, use the runs.subscribeToRun, runs.subscribeToRunsWithTag, and runs.subscribeToBatch APIs as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using lifecycle hooks (init, cleanup, onStart, onSuccess, onFailure, handleError), implement 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:25.014Z
Learning: Applies to trigger.config.ts : Global lifecycle hooks, telemetry, runtime, machine settings, log level, max duration, and build configuration must be set in trigger.config.ts as shown.
apps/webapp/app/presenters/v3/EnvironmentQueuePresenter.server.ts (5)
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.180Z
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.180Z
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.180Z
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.180Z
Learning: Do not use or add new code to the legacy run engine; focus on using and migrating to Run Engine 2.0 in @internal/run-engine.
apps/webapp/app/v3/services/pauseEnvironment.server.ts (1)
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/routes/admin.api.v1.orgs.$organizationId.runs.enable.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: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using Realtime features, use the runs.subscribeToRun, runs.subscribeToRunsWithTag, and runs.subscribeToBatch APIs as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : The run function contains your task logic in Trigger.dev tasks.
🧬 Code Graph Analysis (2)
apps/webapp/app/components/navigation/OrganizationSettingsSideMenu.tsx (3)
apps/webapp/app/components/navigation/SideMenuItem.tsx (1)
SideMenuItem(7-53)apps/webapp/app/utils/pathBuilder.ts (1)
v3BillingAlertsPath(462-464)apps/webapp/app/components/primitives/Badge.tsx (1)
Badge(19-25)
apps/webapp/app/v3/services/pauseEnvironment.server.ts (1)
apps/webapp/app/routes/_app.orgs.$organizationSlug.projects.$projectParam.env.$envParam.queues/route.tsx (1)
action(137-217)
⏰ 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 / webapp / 🧪 Unit Tests: Webapp (10, 10)
- 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 / webapp / 🧪 Unit Tests: Webapp (5, 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 / webapp / 🧪 Unit Tests: Webapp (4, 10)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (4, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (3, 10)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (7, 8)
- 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 (8, 8)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - pnpm)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (2, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
- GitHub Check: units / packages / 🧪 Unit Tests: Packages (1, 1)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - npm)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
- GitHub Check: typecheck / typecheck
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (13)
apps/webapp/app/routes/_app.orgs.$organizationSlug.settings.billing/route.tsx (1)
3-3: Import path update looks correctSwitching to the root
@trigger.dev/platformexport matches the package upgrade to 1.0.17 and keeps the import surface consistent with other files modified in this PR.
No further action required.apps/webapp/package.json (1)
116-116: Confirm the@trigger.dev/platformbump doesn’t introduce breaking changesThe jump from
1.0.15→1.0.17should be safe, but double-check:
- API surface between those versions (changelog / release notes).
- Type-checking & runtime tests still pass.
If everything compiles cleanly, no further work is needed.
apps/webapp/app/routes/resources.orgs.$organizationSlug.select-plan.tsx (1)
14-20: No leftover “@trigger.dev/platform/v3” imports detectedI ran
rg --glob "apps/webapp/**" "@trigger\.dev/platform/v3"across the webapp source and found no matches. All plan-related types are now consistently imported from"@trigger.dev/platform".apps/webapp/app/utils/pathBuilder.ts (1)
462-464: New helper is concise and follows existing naming
v3BillingAlertsPathmirrors the other V3 helpers and keeps URL construction centralised—nice addition.apps/webapp/app/routes/_app.orgs.$organizationSlug.projects.$projectParam.env.$envParam.queues/route.tsx (1)
288-288: LGTM! Proper integration of runsEnabled flag.The conditional rendering correctly hides the pause/resume button when runs are disabled at the organization level, preventing user confusion and inappropriate actions.
apps/webapp/app/components/billing/UpgradePrompt.tsx (1)
33-34: Improved messaging accuracy.The updated text better reflects the actual system behavior when free credits are exceeded - existing runs are queued rather than completely blocked, which provides clearer expectations for users.
apps/webapp/app/presenters/v3/EnvironmentQueuePresenter.server.ts (2)
11-11: Good addition of runsEnabled property.The new boolean property properly extends the Environment type to support organization-level run control.
45-45: Excellent logic for runsEnabled flag.The implementation correctly ensures development environments always have runs enabled while respecting the organization setting for other environment types. This maintains developer workflow while allowing production controls.
apps/webapp/app/components/navigation/OrganizationSettingsSideMenu.tsx (3)
2-2: Proper icon import.The BellAlertIcon import is appropriate for the billing alerts feature.
16-16: Good path utility import.The v3BillingAlertsPath import follows the established pattern for navigation path utilities.
72-99: Well-structured navigation menu addition.The billing alerts menu item is properly integrated:
- Follows existing SideMenuItem patterns
- Uses appropriate icon and active color (rose-500)
- Correctly placed within the managed cloud section
- Maintains consistent data-action attribute
The refactoring to use a fragment also improves code organization.
apps/webapp/app/routes/admin.api.v1.orgs.$organizationId.runs.enable.ts (2)
26-46: Good authentication and authorization logic.The API properly authenticates using personal access tokens and verifies admin privileges. The error messages are appropriate and security-conscious.
91-96: Good response structure.The API response provides clear success indication and meaningful message about the number of environments affected.
apps/webapp/app/routes/_app.orgs.$organizationSlug.settings.billing-alerts/route.tsx
Outdated
Show resolved
Hide resolved
apps/webapp/app/routes/_app.orgs.$organizationSlug.settings.billing-alerts/route.tsx
Show resolved
Hide resolved
apps/webapp/app/routes/_app.orgs.$organizationSlug.settings.billing-alerts/route.tsx
Outdated
Show resolved
Hide resolved
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Description