feat(webapp): dashboard agent — chat, reports, investigate - #4418
feat(webapp): dashboard agent — chat, reports, investigate#4418kathiekiwi wants to merge 490 commits into
Conversation
🦋 Changeset detectedLatest commit: 5126bae The changes in this PR will be included in the next version bump. This PR includes changesets to release 27 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughThis PR adds dashboard-agent contracts, tools, persistence, investigations, watches, evaluation controls, and maintenance jobs. It adds delegated-token environment scoping and shared API authentication. It adds report schemas, JSON responses, health telemetry handling, caching, and rendering updates. It adds waiting-run diagnosis and queue-metrics routes. It also adds request limits, CSP image policies, agent UI updates, tests, documentation, and configuration changes. 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
@trigger.dev/build
trigger.dev
@trigger.dev/core
@trigger.dev/python
@trigger.dev/react-hooks
@trigger.dev/redis-worker
@trigger.dev/rsc
@trigger.dev/schema-to-json
@trigger.dev/sdk
commit: |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
internal-packages/dashboard-agent/src/tool-schemas.ts (1)
547-559: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winAlign the capability instructions with the new mutating tools.
The prompt now exposes
schedule_watch,create_alert, anddelete_alert, but it still describes the toolset as read-only and later says the agent cannot change anything. This contradiction can make the agent refuse supported watch/alert actions or incorrectly direct users to the dashboard. Update the blanket capability text to distinguish read-only data tools from these explicitly authorized mutations.
🧹 Nitpick comments (1)
apps/webapp/app/components/dashboard-agent/DashboardAgentMessages.tsx (1)
351-368: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick winMemoize the transcript-derived winner map.
Line 357 creates a new
Mapon every render, and Line 368 passes it tomemoized turns; activity-only updates therefore rerender the entire transcript and rescan all parts. Memoizestrippedand its winners frommessages.Proposed change
- const stripped = messages.map(stripStepParts); - - const investigationWinners = winningInvestigationOccurrences(stripped); + const { stripped, investigationWinners } = useMemo(() => { + const stripped = messages.map(stripStepParts); + return { + stripped, + investigationWinners: winningInvestigationOccurrences(stripped), + }; + }, [messages]);As per coding guidelines,
useMemois appropriate for expensive derived data and stable references required by dependency arrays.Source: Coding guidelines
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: ae8860fd-cece-44f8-b032-c969b4234488
📒 Files selected for processing (2)
apps/webapp/app/components/dashboard-agent/DashboardAgentMessages.tsxinternal-packages/dashboard-agent/src/tool-schemas.ts
📜 Review details
⏰ Context from checks skipped due to timeout. (33)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (12, 12)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (11, 12)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (7, 12)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (6, 12)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (4, 12)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (5, 12)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (1, 12)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (8, 12)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (10, 12)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (9, 12)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (3, 12)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (2, 12)
- GitHub Check: sdk-compat / Node.js 22.23 (warp-ubuntu-latest-x64-4x)
- GitHub Check: sdk-compat / Node.js 24.18 (warp-ubuntu-latest-x64-4x)
- GitHub Check: sdk-compat / Bun Runtime
- GitHub Check: sdk-compat / Node.js 26.4 (warp-ubuntu-latest-x64-4x)
- GitHub Check: sdk-compat / Node.js 20.20 (warp-ubuntu-latest-x64-4x)
- GitHub Check: e2e / 🧪 CLI v3 tests (warp-ubuntu-latest-x64-4x - pnpm)
- GitHub Check: e2e / 🧪 CLI v3 tests (warp-windows-latest-x64-8x - pnpm)
- GitHub Check: typecheck / typecheck
- GitHub Check: e2e / 🧪 CLI v3 tests (warp-ubuntu-latest-x64-4x - npm)
- GitHub Check: e2e / 🧪 CLI v3 tests (warp-windows-latest-x64-8x - npm)
- GitHub Check: packages / 🧪 Unit Tests: Packages (2, 3)
- GitHub Check: packages / 🧪 Unit Tests: Packages (3, 3)
- GitHub Check: packages / 🧪 Unit Tests: Packages (1, 3)
- GitHub Check: sdk-compat / Cloudflare Workers
- GitHub Check: sdk-compat / Deno Runtime
- GitHub Check: runops-guard / runops-guard
- GitHub Check: internal / 🧪 Unit Tests: Internal
- GitHub Check: e2e-webapp / 🧪 E2E Tests: Webapp
- GitHub Check: code-quality / code-quality
- GitHub Check: 🛡️ E2E Auth Tests (full)
- GitHub Check: Analyze (javascript-typescript)
🧰 Additional context used
📓 Path-based instructions (8)
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
**/*.{ts,tsx}: Use types over interfaces for TypeScript
Avoid using enums; prefer string unions or const objects instead
**/*.{ts,tsx}: Prefer static imports over dynamicimport(); use dynamic imports only for unresolvable circular dependencies, genuine performance code splitting, or conditional runtime loading.
Import Trigger.dev tasks from@trigger.dev/sdk; never use@trigger.dev/sdk/v3or deprecatedclient.defineJob.
Add agentcrumbs while writing code using approved namespaces; mark lines with//@Crumbsor blocks with `// `#region` `@crumbs, and strip them before merging.
Files:
apps/webapp/app/components/dashboard-agent/DashboardAgentMessages.tsxinternal-packages/dashboard-agent/src/tool-schemas.ts
{packages/core,apps/webapp}/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use zod for validation in packages/core and apps/webapp
Files:
apps/webapp/app/components/dashboard-agent/DashboardAgentMessages.tsx
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use function declarations instead of default exports
Files:
apps/webapp/app/components/dashboard-agent/DashboardAgentMessages.tsxinternal-packages/dashboard-agent/src/tool-schemas.ts
apps/webapp/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/webapp.mdc)
apps/webapp/**/*.{ts,tsx}: Access environment variables through theenvexport ofenv.server.tsinstead of directly accessingprocess.env
Use subpath exports from@trigger.dev/corepackage instead of importing from the root@trigger.dev/corepathDo not reintroduce the removed v1 execution path;
RunEngineVersion.V1branches may only reject or finalize gracefully so v3 clients receive a clean 4xx, never a 5xx.
Files:
apps/webapp/app/components/dashboard-agent/DashboardAgentMessages.tsx
apps/**/*.{ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
For apps, use
typecheckfor verification and never usebuildas the correctness check.
Files:
apps/webapp/app/components/dashboard-agent/DashboardAgentMessages.tsx
apps/webapp/app/**/*.{ts,tsx}
📄 CodeRabbit inference engine (apps/webapp/CLAUDE.md)
apps/webapp/app/**/*.{ts,tsx}: For dashboard changes, visually verify the running Remix app with Chrome DevTools MCP, using snapshots, screenshots, interaction, and console-message checks as appropriate.
UseuseCallbackanduseMemoonly for context provider values, expensive derived data used as a dependency, or stable references required by dependency arrays; do not wrap ordinary event handlers or trivial computations.
Use named constants for sentinel or placeholder values instead of scattering raw string literals across comparisons.
Files:
apps/webapp/app/components/dashboard-agent/DashboardAgentMessages.tsx
**/*.ts
📄 CodeRabbit inference engine (.cursor/rules/otel-metrics.mdc)
**/*.ts: When creating or editing OTEL metrics (counters, histograms, gauges), ensure metric attributes have low cardinality by using only enums, booleans, bounded error codes, or bounded shard IDs
Do not use high-cardinality attributes in OTEL metrics such as UUIDs/IDs (envId, userId, runId, projectId, organizationId), unbounded integers (itemCount, batchSize, retryCount), timestamps (createdAt, startTime), or free-form strings (errorMessage, taskName, queueName)
When exporting OTEL metrics via OTLP to Prometheus, be aware that the exporter automatically adds unit suffixes to metric names (e.g., 'my_duration_ms' becomes 'my_duration_ms_milliseconds', 'my_counter' becomes 'my_counter_total'). Account for these transformations when writing Grafana dashboards or Prometheus queries
Files:
internal-packages/dashboard-agent/src/tool-schemas.ts
internal-packages/**/*.{ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
For internal packages, use
typecheckfor verification and never usebuildas the correctness check.
Files:
internal-packages/dashboard-agent/src/tool-schemas.ts
🧠 Learnings (18)
📚 Learning: 2026-02-11T16:37:32.429Z
Learnt from: matt-aitken
Repo: triggerdotdev/trigger.dev PR: 3019
File: apps/webapp/app/components/primitives/charts/Card.tsx:26-30
Timestamp: 2026-02-11T16:37:32.429Z
Learning: In projects using react-grid-layout, avoid relying on drag-handle class to imply draggability. Ensure drag-handle elements only affect dragging when the parent grid item is configured draggable in the layout; conditionally apply cursor styles based on the draggable prop. This improves correctness and accessibility.
Applied to files:
apps/webapp/app/components/dashboard-agent/DashboardAgentMessages.tsx
📚 Learning: 2026-07-28T21:57:20.061Z
Learnt from: samejr
Repo: triggerdotdev/trigger.dev PR: 4411
File: apps/webapp/app/routes/_app.orgs.$organizationSlug.settings.team/route.tsx:818-843
Timestamp: 2026-07-28T21:57:20.061Z
Learning: When using Radix UI `DialogClose` with `asChild` (e.g., Trigger.dev dashboard components), note that it injects `type="button"` into its child via `Slot`. If the child is a local `Button` that forwards its `type` prop to the native `<button>`, then placing it inside a `<form>` will *not* submit unless you explicitly set `type="submit"` (or otherwise override the injected type / wire up submission behavior). Review form actions to ensure the intended submit vs non-submit behavior is preserved.
Applied to files:
apps/webapp/app/components/dashboard-agent/DashboardAgentMessages.tsx
📚 Learning: 2026-03-22T13:26:12.060Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 3244
File: apps/webapp/app/components/code/TextEditor.tsx:81-86
Timestamp: 2026-03-22T13:26:12.060Z
Learning: In the triggerdotdev/trigger.dev codebase, do not flag `navigator.clipboard.writeText(...)` calls for `missing-await`/`unhandled-promise` issues. These clipboard writes are intentionally invoked without `await` and without `catch` handlers across the project; keep that behavior consistent when reviewing TypeScript/TSX files (e.g., usages like in `apps/webapp/app/components/code/TextEditor.tsx`).
Applied to files:
apps/webapp/app/components/dashboard-agent/DashboardAgentMessages.tsxinternal-packages/dashboard-agent/src/tool-schemas.ts
📚 Learning: 2026-03-22T19:24:14.403Z
Learnt from: matt-aitken
Repo: triggerdotdev/trigger.dev PR: 3187
File: apps/webapp/app/v3/services/alerts/deliverErrorGroupAlert.server.ts:200-204
Timestamp: 2026-03-22T19:24:14.403Z
Learning: In the triggerdotdev/trigger.dev codebase, webhook URLs are not expected to contain embedded credentials/secrets (e.g., fields like `ProjectAlertWebhookProperties` should only hold credential-free webhook endpoints). During code review, if you see logging or inclusion of raw webhook URLs in error messages, do not automatically treat it as a credential-leak/secrets-in-logs issue by default—first verify the URL does not contain embedded credentials (for example, no username/password in the URL, no obvious secret/token query params or fragments). If the URL is credential-free per this project’s conventions, allow the logging.
Applied to files:
apps/webapp/app/components/dashboard-agent/DashboardAgentMessages.tsxinternal-packages/dashboard-agent/src/tool-schemas.ts
📚 Learning: 2026-05-18T08:21:27.694Z
Learnt from: d-cs
Repo: triggerdotdev/trigger.dev PR: 3632
File: apps/webapp/sentry.server.ts:4-21
Timestamp: 2026-05-18T08:21:27.694Z
Learning: When handling Prisma error P1001 ("Can't reach database server") in TypeScript, don’t assume a single error shape. Prisma can surface P1001 via two different error classes/fields: `PrismaClientKnownRequestError` exposes it as `err.code === "P1001"` (common during mid-query connection drops), while `PrismaClientInitializationError` exposes it as `err.errorCode === "P1001"` (common on client startup failure). Therefore, predicates should use `err.code === "P1001" || err.errorCode === "P1001"`. Do not flag `err.code === "P1001"` as “unreachable/never matches,” as it is expected in production.
Applied to files:
apps/webapp/app/components/dashboard-agent/DashboardAgentMessages.tsxinternal-packages/dashboard-agent/src/tool-schemas.ts
📚 Learning: 2026-05-18T08:21:27.694Z
Learnt from: d-cs
Repo: triggerdotdev/trigger.dev PR: 3632
File: apps/webapp/sentry.server.ts:4-21
Timestamp: 2026-05-18T08:21:27.694Z
Learning: When handling Prisma errors for P1001 ("Can't reach database server"), do not assume it only appears under a single property name. Prisma may surface P1001 via either `PrismaClientKnownRequestError` (`err.code === "P1001"`, e.g., mid-query connection drops) or `PrismaClientInitializationError` (`err.errorCode === "P1001"`, e.g., client startup connection failure). To reliably detect the condition, check `err.code === "P1001" || err.errorCode === "P1001"`, and avoid review rules that would incorrectly flag `err.code === "P1001"` as unreachable/never-matching.
Applied to files:
apps/webapp/app/components/dashboard-agent/DashboardAgentMessages.tsxinternal-packages/dashboard-agent/src/tool-schemas.ts
📚 Learning: 2026-06-13T19:53:13.759Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 3937
File: packages/trigger-sdk/skills/realtime-and-frontend/SKILL.md:258-260
Timestamp: 2026-06-13T19:53:13.759Z
Learning: When reviewing code that uses `trigger.dev/react-hooks`’s `useRealtimeRun`, preserve the call signature where the first argument is the full realtime handle object (not `handle.id`). This is intentional to maintain type-safety and is consistent with the official docs; do not suggest changing the first argument from the handle object to `handle.id`.
Applied to files:
apps/webapp/app/components/dashboard-agent/DashboardAgentMessages.tsxinternal-packages/dashboard-agent/src/tool-schemas.ts
📚 Learning: 2026-06-17T17:13:49.929Z
Learnt from: matt-aitken
Repo: triggerdotdev/trigger.dev PR: 3948
File: apps/webapp/app/routes/_app.orgs.$organizationSlug.projects.$projectParam.env.$envParam.bulk-actions.$bulkActionParam/route.tsx:48-62
Timestamp: 2026-06-17T17:13:49.929Z
Learning: In triggerdotdev/trigger.dev, within `dashboardLoader`/`dashboardAction` (or similar context resolver code) whenever you resolve an organization ID from an organization slug for RBAC/enterprise authorization scope, always read from the primary Prisma client (`prisma`), not `$replica`. Using `$replica` can hit replica-lag and cause the RBAC lookup/authorization to run without the correct org scope (bypassing intended role enforcement). Implement the slug→org lookup with `prisma.organization.findFirst(...)` (or equivalent primary-client query) and add an inline comment documenting why the primary client is required (replica lag could lead to unscoped RBAC checks).
Applied to files:
apps/webapp/app/components/dashboard-agent/DashboardAgentMessages.tsxinternal-packages/dashboard-agent/src/tool-schemas.ts
📚 Learning: 2026-06-23T13:04:21.413Z
Learnt from: carderne
Repo: triggerdotdev/trigger.dev PR: 4023
File: apps/webapp/app/services/upsertBranch.server.ts:14-18
Timestamp: 2026-06-23T13:04:21.413Z
Learning: In TypeScript, it’s valid to `import { type X }` and then use `typeof X` in a type-only position, e.g. `type Alias = z.infer<typeof X>`. The `type` modifier suppresses the runtime import, but the type checker still has the full exported type so `z.infer<typeof X>` can resolve correctly. In code reviews, don’t flag this as a TypeScript compile error as long as `typeof X` is used in a type context (e.g., with `z.infer`, `type` aliases, generics), not as a runtime value.
Applied to files:
apps/webapp/app/components/dashboard-agent/DashboardAgentMessages.tsxinternal-packages/dashboard-agent/src/tool-schemas.ts
📚 Learning: 2026-04-16T14:21:15.229Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 3368
File: apps/webapp/app/components/logs/LogsTaskFilter.tsx:135-163
Timestamp: 2026-04-16T14:21:15.229Z
Learning: When rendering lists of task registry items in apps/webapp (e.g., <SelectItem /> rows) and using `key={item.slug}`, do not flag it as potentially non-unique. In trigger.dev’s `TaskIdentifier` table, the DB constraint `@unique([runtimeEnvironmentId, slug])` guarantees `slug` is unique within a given runtime environment, so `item.slug` is safe as the React key as long as the list is derived from that registry/constraint (and not from a legacy query that could produce duplicate slugs).
Applied to files:
apps/webapp/app/components/dashboard-agent/DashboardAgentMessages.tsx
📚 Learning: 2026-05-08T21:00:20.973Z
Learnt from: samejr
Repo: triggerdotdev/trigger.dev PR: 3538
File: apps/webapp/app/components/primitives/Resizable.tsx:60-78
Timestamp: 2026-05-08T21:00:20.973Z
Learning: In the triggerdotdev/trigger.dev codebase, treat Zod as a boundary validation tool (API handlers, request/response validation, and storage/DB read/write validation), not as inline render-time validation inside React components/primitive UI code. For render-time guards, prefer small manual type-narrowing checks (e.g., a short predicate like ~10–20 lines) over importing Zod into UI primitives, to avoid per-render schema-parse overhead and unnecessary abstraction. Use the manual guard approach unless you truly need schema validation at a boundary; only then introduce Zod.
Applied to files:
apps/webapp/app/components/dashboard-agent/DashboardAgentMessages.tsx
📚 Learning: 2026-06-25T18:21:55.847Z
Learnt from: carderne
Repo: triggerdotdev/trigger.dev PR: 4039
File: apps/webapp/app/routes/invite-resend.tsx:0-0
Timestamp: 2026-06-25T18:21:55.847Z
Learning: In the triggerdotdev/trigger.dev Zod 4 migration, avoid importing from the root package `conform-to/zod` in webapp code. It can resolve to the Zod 3 build and may crash at module load under Zod 4. When reviewing TypeScript/TSX files in `apps/webapp`, prefer importing from the Zod 4 subpath `conform-to/zod/v4` for Zod 4-compatible schemas/types.
Applied to files:
apps/webapp/app/components/dashboard-agent/DashboardAgentMessages.tsx
📚 Learning: 2026-05-12T21:04:05.815Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 3542
File: apps/webapp/app/components/sessions/v1/SessionStatus.tsx:1-3
Timestamp: 2026-05-12T21:04:05.815Z
Learning: In this Remix + TypeScript codebase, do not flag a server/client boundary violation when a file imports only types from a module matching `*.server`.
Specifically, it’s safe to import types using `import type { Foo } from "*.server"` or `import { type Foo } from "*.server"` because TypeScript erases type-only imports at compile time and they emit no JavaScript, so they won’t cross the Remix server/client bundle boundary.
Only raise the boundary concern for value imports (e.g., `import { Foo }` without `type`, or `import Foo`), since those produce JavaScript output.
Applied to files:
apps/webapp/app/components/dashboard-agent/DashboardAgentMessages.tsx
📚 Learning: 2026-06-25T18:21:51.905Z
Learnt from: carderne
Repo: triggerdotdev/trigger.dev PR: 4039
File: apps/webapp/app/routes/invite-revoke.tsx:0-0
Timestamp: 2026-06-25T18:21:51.905Z
Learning: During the Zod v4 migration in the triggerdotdev/trigger.dev webapp, ensure any imports from `conform-to/zod` use the Zod-4 subpath: `conform-to/zod/v4` (e.g., `import { parseWithZod } from "conform-to/zod/v4"`). Do not import from the package root `conform-to/zod`, because it is the Zod 3 implementation and may load Zod-3-only symbols (e.g., `ZodBranded`, `ZodEffects`), which can throw at module load (notably with `zod4.4.3`). This should be enforced across `apps/webapp/**/*` where helpers like `parseWithZod` and `conformZodMessage` are used.
Applied to files:
apps/webapp/app/components/dashboard-agent/DashboardAgentMessages.tsx
📚 Learning: 2026-07-03T17:10:21.498Z
Learnt from: 0ski
Repo: triggerdotdev/trigger.dev PR: 4148
File: apps/webapp/app/models/orgMember.server.ts:149-168
Timestamp: 2026-07-03T17:10:21.498Z
Learning: In triggerdotdev/trigger.dev, `User.email` (Prisma schema: `internal-packages/database/prisma/schema.prisma`) currently does NOT use `citext` and does NOT have a `lower(email)` functional unique index. Therefore, do not introduce Prisma queries like `where: { email: { equals: <value>, mode: "insensitive" } }` (or any case-insensitive lookup) against `User.email`, because it can force sequential scans of the `users` table under load. During review, ensure email is normalized (e.g., lowercased/trimmed) before both writes and subsequent lookups, and if true case-insensitive behavior/uniqueness is required, implement it via a separate app-wide migration (e.g., switch to `citext` and/or add a functional unique index with backfill) rather than bolting it onto individual feature PRs.
Applied to files:
apps/webapp/app/components/dashboard-agent/DashboardAgentMessages.tsx
📚 Learning: 2026-06-25T18:21:54.729Z
Learnt from: carderne
Repo: triggerdotdev/trigger.dev PR: 4039
File: apps/webapp/app/routes/confirm-basic-details.tsx:0-0
Timestamp: 2026-06-25T18:21:54.729Z
Learning: For Remix + TypeScript files that use Conform v1 (conform-to/react) and its getInputProps helper, when you intend to suppress the helper-provided default value for non-checkbox/non-radio inputs (e.g., hidden inputs managed via an explicit value prop), use the Conform v1 option key `value: false`. Do not recommend `defaultValue: false` here, because `defaultValue` is not a valid option key for these input types in Conform v1 typings.
Applied to files:
apps/webapp/app/components/dashboard-agent/DashboardAgentMessages.tsx
📚 Learning: 2026-06-04T18:16:35.386Z
Learnt from: nicktrn
Repo: triggerdotdev/trigger.dev PR: 3836
File: apps/supervisor/src/backpressure/backpressureMonitor.ts:3-5
Timestamp: 2026-06-04T18:16:35.386Z
Learning: When reviewing TypeScript in this repo, apply the rule “prefer type aliases over interfaces” only to data/object shapes and union/intersection type modeling. If an interface is being used as a behavioral contract for collaborators to implement (e.g., method-shape interfaces that define required behavior, such as `BackpressureLogger` / `BackpressureSignalSource` in `apps/supervisor/src/backpressure/backpressureMonitor.ts`), keep it as an `interface` and do not flag it as a type-alias-vs-interface violation.
Applied to files:
internal-packages/dashboard-agent/src/tool-schemas.ts
📚 Learning: 2026-06-09T17:58:04.699Z
Learnt from: 0ski
Repo: triggerdotdev/trigger.dev PR: 3879
File: apps/webapp/app/models/vercelIntegration.server.ts:619-630
Timestamp: 2026-06-09T17:58:04.699Z
Learning: In this codebase, outbound raw `fetch` calls should typically rely on Node/undici’s default request timeout (about ~300s) rather than adding a per-call `AbortController` + `setTimeout` wrapper inside individual functions (e.g. in files like `apps/webapp/app/models/vercelIntegration.server.ts`). During code review, do not flag the absence of a per-call timeout on a single `fetch` as an issue; if per-call timeouts are needed, they should be implemented via a codebase-wide convention (e.g., a shared fetch wrapper or documented pattern) rather than ad-hoc per-function changes.
Applied to files:
internal-packages/dashboard-agent/src/tool-schemas.ts
🔇 Additional comments (1)
apps/webapp/app/components/dashboard-agent/DashboardAgentMessages.tsx (1)
99-146: LGTM!Also applies to: 245-287
kathiekiwi
changed the title
- waiting-run diagnosis: 'unknown' with concurrency evidence in hand no longer claims the evidence is missing; an elapsed delay says 'not yet enqueued' instead of hiding behind time-from-creation - queue metrics route: drop the double decode that 500ed on names with a literal percent sign - evidence schema: kind must match the URI's own kind - seed-queue-metrics: default-binding imports like the other seeders
kathiekiwi
changed the title
A chart block's TRQL query used to run only in the panel, after the turn, so a bad query left a broken chart the model never learned about. render_view now runs each chart query through the query API first and fails by name with the query error, so the model fixes it in the same turn. The rows are discarded — the panel stays the runner. Skipped when the turn has no delegated token or the validation request itself fails.
Markdown renderers won't link an unknown scheme, so a cited trigger:// target rendered dead. Prose links now rewrite through the panel's resolver; while unresolved they degrade to their plain label.
…s at something worth monitoring
…headline is an unresolved recurring error
Observability mapAs of 19/100 over 417 measured of 433 entry points (base 18, up 1) What this PR changed
FIX FIRST
AUDIT 3 of 50 sensitive mutations record an actor. 47 without one. What the score is made ofThe score and findings here are report-only and never gate the merge. Separately, a required test suite keeps this tool's symbol and route lists in sync with the code they name, and can fail a pull request that renames or removes a symbol they reference, or that adds the first route with a segment they anticipate. Each failure names the list to edit. The rules and their reasons: internal-packages/observability-map/README.md. |
The Badge primitive's small variant paints a blue tinted chip on system themes, which overrode the severity/confidence tones — Degraded and Medium confidence rendered blue instead of amber.
New "actions" view block: a row of 1-3 buttons the model may emit. A watch action opens the watch configuration card pre-filled; ask sends the labelled question as the user's next message; a navigate target that doesn't parse is dropped at render time, as on chart actions.
…ger button Agent logo instead of the indigo bubble, the button's own surface (charcoal on dark, white on light) and softened green border.
Third ToastUI variant: success's layout with the agent glyph and the Ask Trigger border. The wake toast drops its Callout composition for it.
…allery section id The wake toast moved to the standard toast's agent status, leaving the Callout variant with no consumer.
The root already mounts one; a fired toast rendered in both and the two copies stacked.
Sonner stamps data-theme="light" (its default) on the toast list; since the theme system remaps tokens by that attribute, every custom toast rendered light regardless of the page's theme.
…ays the side panel
…flows # Conflicts: # apps/webapp/app/routes/_app.orgs.$organizationSlug.projects.$projectParam.env.$envParam.apikeys/route.tsx
0000 and 0001 already shipped, so the agent's new tables land in a third migration instead of a squashed first one.
The system — contracts, storage, auth, the agent package and its webapp routes — lands first; the panel, the page-context marks and the entry points follow in their own PR.
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| // The `ask` param is picked up in the environment layout (`useDashboardAgentOpenRequests`). | ||
| newUrl.searchParams.set("ask", query); |
There was a problem hiding this comment.
🟡 The "ask AI" deep link from outside the dashboard now opens nothing
The redirect that carries a user's question into the dashboard now attaches it under a name nothing reads (newUrl.searchParams.set("ask", query) at apps/webapp/app/routes/projects.$projectRef.ai-help.ts:49), so the question is dropped and the assistant never opens.
Impact: Someone following an "ask AI" link lands on the dashboard with their question silently discarded and no assistant open.
The old parameter had a reader; the new one does not
The route previously set aiHelp, which was consumed by apps/webapp/app/components/AskAI.tsx:70-77 (searchParams.get("aiHelp") → openAskAI(aiHelp)). This PR deprecates AskAI.tsx and states that nothing mounts it any more, and switches the redirect to ask.
The comment on line 48 says the ask param is "picked up in the environment layout (useDashboardAgentOpenRequests)", but there is no such symbol anywhere in the repository, and no file reads searchParams.get("ask") — a grep over apps/webapp/app (including app/components/dashboard-agent/) returns only this comment. So the parameter is written and never consumed.
Prompt for agents
`apps/webapp/app/routes/projects.$projectRef.ai-help.ts` redirects into the dashboard with the user's question in a search param. It used to write `aiHelp`, which `apps/webapp/app/components/AskAI.tsx` read and used to open the Ask AI dialog. This PR deprecates AskAI (nothing mounts it) and changes the param to `ask`, with a comment claiming the environment layout picks it up via `useDashboardAgentOpenRequests`. No such hook exists in the repo, and nothing reads a search param named `ask`. Either add the reader in the environment layout that opens the dashboard-agent panel and seeds the composer/first message from `?ask=`, then strips the param, or keep the redirect pointing at whatever surface actually consumes it today.
Was this helpful? React with 👍 or 👎 to provide feedback.
| if (checkMessageParts(parsed.payload.message?.parts) !== null) { | ||
| return tooLarge(); | ||
| } | ||
| parsed.payload.metadata = { | ||
| ...(parsed.payload.metadata ?? {}), | ||
| userActorToken: await mintDashboardAgentUserActorToken(user.id), | ||
| ...pickAgentClientMetadata(parsed.payload.metadata), |
There was a problem hiding this comment.
🟡 A failure to mint the agent's access token is treated as a malformed message and the turn is sent without any access
The step that creates the chat's short-lived access credential (mintDashboardAgentUserActorToken(...) inside the try at apps/webapp/app/routes/resources.$organizationSlug.projects.$projectParam.env.$envParam.dashboard-agent.in.$.ts:117-121) is covered by a catch meant for unreadable message bodies, so a failure there is ignored and the message is forwarded with no credential attached.
Impact: If credential creation fails, the assistant answers the question with no access to the user's data and claims it can't see anything, instead of reporting an error.
The catch's intent versus what it covers
The try block was written around JSON.parse(raw) — its catch comment reads "Non-JSON or unexpected shape — forward unchanged rather than break the turn." But the awaited mint call is inside the same block, so any rejection from it (signing error, missing secret) takes the same path: body stays as the raw, un-augmented request and is proxied upstream. The agent then runs the turn with no userActorToken, apiOrigin, projectRef, environmentId or repo snapshot in its metadata, and every data tool falls into its no-auth branch (NO_AUTH in internal-packages/dashboard-agent/src/tool-api-client.ts).
Narrowing the try to the JSON.parse call (or awaiting the mint before entering it) makes a mint failure surface as a 5xx the client can retry.
Was this helpful? React with 👍 or 👎 to provide feedback.
| bucketIntervalMs: bucketSeconds * 1000, | ||
| // Oldest first; buckets with no sample are omitted, so gaps carry the previous depth. | ||
| depthTrend: (trendRows ?? []) | ||
| .slice() | ||
| .sort((a, b) => a.bucket.localeCompare(b.bucket)) | ||
| .map((row) => row.depth), |
There was a problem hiding this comment.
🟡 Queue depth trend can be mis-timed when a bucket reports no data
The queue depth series drops any interval that reported nothing (.map((row) => row.depth) at apps/webapp/app/routes/api.v1.queues.$queueParam.metrics.ts:120-123) while still being labelled with a fixed interval width, so the points shift in time whenever a gap exists.
Impact: A queue's depth-over-time answer can place values at the wrong times after any quiet interval.
The comment describes carry-forward, but the code omits
The inline comment says "buckets with no sample are omitted, so gaps carry the previous depth", but omitting a bucket does not carry the previous depth — it compresses the timeline, so the Nth element of depthTrend no longer corresponds to from + N * bucketIntervalMs.
The sibling reader does this correctly: apps/webapp/app/presenters/v3/waitingRun/waitingRunDiagnosis.server.ts:138-146 builds a fixed-width grid and carry-forwards the last known depth into missing buckets. Applying the same fill here (or returning { bucket, depth } pairs) would make bucketIntervalMs meaningful.
Was this helpful? React with 👍 or 👎 to provide feedback.
| argsSchema: { | ||
| key: completable(z.string().optional(), (value) => | ||
| key: completable(ReportKeySchema.optional(), (value) => | ||
| REPORT_KEYS.filter((k) => k.startsWith(value ?? "")) | ||
| ), | ||
| environment: completable(z.string().optional(), (value) => | ||
| environment: completable(ReportEnvironmentSchema.optional(), (value) => | ||
| ENVIRONMENTS.filter((e) => e.startsWith(value ?? "")) | ||
| ), | ||
| // Plain string on purpose: MCP prompt args must be simple string schemas (the SDK | ||
| // introspects them as such), and this only forwards into get_report, which validates | ||
| // the period with the shared ReportPeriodSchema. Don't swap in a refined schema here. | ||
| period: z.string().optional(), | ||
| period: ReportPeriodSchema.optional(), |
There was a problem hiding this comment.
🔍 The MCP prompt args now use refined/enum schemas, against the removed comment's warning
The deleted comment explicitly said "MCP prompt args must be simple string schemas (the SDK introspects them as such) … Don't swap in a refined schema here", and this change swaps in ReportKeySchema (ZodEnum), ReportEnvironmentSchema (ZodEnum) and ReportPeriodSchema (ZodEffects over ZodString). All three are still ZodType<string> so the SDK's PromptArgsRawShape type is satisfied, and the SDK derives prompt arguments via isOptional()/description rather than requiring ZodString, so this should work — but it is worth confirming against the pinned @modelcontextprotocol/sdk version (it isn't installed in this checkout, so I couldn't verify at runtime), particularly that completable() over an optional enum still surfaces completions.
Was this helpful? React with 👍 or 👎 to provide feedback.
| const ROLLOUT_ERROR_PATTERNS = [ | ||
| /\bUNKNOWN_(?:TABLE|IDENTIFIER|DATABASE)\b/, | ||
| /\bCode:\s*(?:60|47|81)\b/, | ||
| /\bTable\b[^.]*\bdoes\s?n?o?t?'?t?\s*exist/i, | ||
| /\bUnknown (?:table|identifier|column|database)\b/i, | ||
| ]; | ||
|
|
||
| function isRolloutError(error: unknown): boolean { | ||
| // Prefer a structured code/type if one ever survives the wrapping. | ||
| if (typeof error === "object" && error !== null) { | ||
| const record = error as Record<string, unknown>; | ||
| const code = String(record.code ?? ""); | ||
| const type = String(record.type ?? ""); | ||
| if (code === "60" || code === "47" || code === "81") return true; | ||
| if (/^UNKNOWN_(TABLE|IDENTIFIER|DATABASE)$/.test(type)) return true; | ||
| } | ||
| const message = | ||
| error instanceof Error | ||
| ? error.message | ||
| : typeof error === "string" | ||
| ? error | ||
| : String(error ?? ""); | ||
| return ROLLOUT_ERROR_PATTERNS.some((pattern) => pattern.test(message)); | ||
| } |
There was a problem hiding this comment.
🔍 Rollout-error detection for env_metrics is text-matched and may misclassify
isRolloutError decides whether a measured-flow failure is a benign "table not there yet" (fall through to the snapshot silently) or a real failure (mark the depth unmeasurable). It first checks record.code/record.type, then falls back to regexes over the error message. Two things to keep in mind: the structured branch compares String(record.code) against "60"|"47"|"81" — a numeric code: 60 stringifies to "60" so that works, but a ClickHouse client that reports code as e.g. "DB::Exception 60" will not match and will fall through to the text patterns. And /\bUnknown (?:table|identifier|column|database)\b/i will also match an unrelated error message that merely contains that phrase (e.g. a bad user-authored query surfaced through the same client), silently downgrading a real failure to "unavailable". Worth confirming the exact error shape the query service produces for a missing env_metrics table.
Was this helpful? React with 👍 or 👎 to provide feedback.
|
Note GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer. |
kathiekiwi
changed the title
There was a problem hiding this comment.
Actionable comments posted: 13
Note
Due to the large number of review comments, Critical, Major severity comments were prioritized as inline comments.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
apps/webapp/app/presenters/v3/reports/health/health.ts (1)
104-118: 🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick winFooter can now exceed the documented maximum of two entries.
raise_env_limitemits two entries. If the dominant finding isflow, the block at Lines 112-118 pushes a third entry (do_nothing_drainsorregion_failover).env_limit_saturationis a flow cause with theraise_env_limitrecommendation, so this path is reachable. Thefooterfield inpackages/core/src/v3/schemas/reports.ts(Line 171) documents "Max two entries". Update that comment, or cap the footer length here, so renderers and clients share one contract.apps/webapp/app/tailwind.css (1)
704-733: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winAdd an empty line before the
background-colordeclarations.Stylelint reports
declaration-empty-line-beforeerrors at Line 707 and Line 733. The rule triggers because a plain declaration follows the@applyat-rule without a blank line.🎨 Proposed fix
& code:not(pre code) { `@apply` px-1 py-0.5 rounded-sm text-text-bright font-mono; + background-color: var(--muted); }& th { `@apply` font-semibold; + background-color: var(--muted); }Source: Linters/SAST tools
🟡 Minor comments (24)
.server-changes/dashboard-agent.md-6-6 (1)
6-6: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winFix the grammar in this published sentence.
The clause "everywhere that used to appear" has no subject. Add the pronoun. This text publishes verbatim as release notes.
📝 Proposed wording
-Meet the dashboard agent: a chat in every environment that answers questions about your runs, queues, errors and health with real data and links. It takes over from Ask AI everywhere that used to appear; on the Free plan you get 20 messages. +Meet the dashboard agent: a chat in every environment that answers questions about your runs, queues, errors and health with real data and links. It takes over from Ask AI everywhere that used to appear; on the Free plan you get 20 messages.Change "everywhere that used to appear" to "everywhere Ask AI used to appear".
Source: Learnings
internal-packages/dashboard-agent/src/tool-curation.ts-84-109 (1)
84-109: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
truncatedreports true for a complete 60-span trace.
truncatedisspans.length >= MAX_TRACE_SPANS. A trace with exactly 60 spans and no further children setstruncated: truealthough no span was dropped. The model then hedges on a complete trace. Set the flag only when a span is actually skipped.🐛 Proposed fix
const MAX_TRACE_SPANS = 60; export function curateTrace(data: unknown) { const root = (data as any)?.trace?.rootSpan; const spans: Array<Record<string, unknown>> = []; + let dropped = false; const walk = (span: any, depth: number) => { - if (!span || spans.length >= MAX_TRACE_SPANS) return; + if (!span) return; + if (spans.length >= MAX_TRACE_SPANS) { + dropped = true; + return; + } const d = span.data ?? {}; @@ walk(root, 0); return { traceId: (data as any)?.trace?.traceId, spans, - truncated: spans.length >= MAX_TRACE_SPANS, + truncated: dropped, }; }apps/webapp/app/components/AskAI.tsx-1-5 (1)
1-5: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winUpdate the deprecation note for live Ask AI mounts.
AskAIRootis still mounted inapps/webapp/app/components/navigation/HelpAndFeedbackPopover.tsx, andAskAIis still mounted fromapps/webapp/app/components/BlankStatePanels.tsx. The comment “nothing mounts this any more” is inaccurate, or the deprecated components/routes need to be removed..changeset/report-json-and-period-units.md-6-6 (1)
6-6: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winClarify the period statement; the examples do not show the stated minimum.
The sentence states that the shortest period is one minute. The examples are
30m,1h, and7d. None of them is one minute. Separate the minimum from the format examples.📝 Proposed wording
-Reports can be fetched as structured data with the `json` format. The shortest report period is now one minute (`30m`, `1h`, `7d`). +Reports can be fetched as structured data with the `json` format. Report periods now accept minute units, for example `30m`, `1h` or `7d`, with a one minute minimum.apps/webapp/app/routes/resources.orgs.$organizationSlug.projects.$projectParam.env.$envParam.dashboard-agent.ts-223-235 (1)
223-235: 🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick winResolve the environment before you create the chat row.
createChatruns at line 225. The environment lookup runs at line 234. If the environment does not resolve, the handler returns 404 and leaves an empty chat row behind. That row then appears inlistChatswith no session and no messages.Move the environment lookup above
createChatso no row is written when the request cannot proceed.🐛 Proposed reorder
const chatId = generateFriendlyId("chat"); try { + // Membership-scoped: dev rows are per-developer, so a token must never be minted for + // someone else's environment — or, when nothing resolves, for no environment at all. + const runtimeEnv = await findEnvironmentBySlug(project.id, envParam, userId); + if (!runtimeEnv) return json({ error: "Environment not found" }, { status: 404 }); + await createChat(dashboardAgentDb, { id: chatId, organizationId: project.organizationId, userId, ...(clientData ? { metadata: { context: clientContext } } : {}), }); - // Membership-scoped: dev rows are per-developer, so a token must never be minted for - // someone else's environment — or, when nothing resolves, for no environment at all. - const runtimeEnv = await findEnvironmentBySlug(project.id, envParam, userId); - if (!runtimeEnv) return json({ error: "Environment not found" }, { status: 404 }); const environmentName = ENV_NAME_BY_TYPE[runtimeEnv.type];apps/webapp/app/presenters/v3/reports/health/health-data.ts-301-306 (1)
301-306: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winTighten the "does not exist" pattern.
/\bTable\b[^.]*\bdoes\s?n?o?t?'?t?\s*exist/imakes every character of the negation optional, so it also matches "Table foo does exist". A false positive here classifies a real failure asunavailable, which the doc comment at lines 280-282 states must never happen. Match the two intended spellings explicitly.🐛 Proposed fix
- /\bTable\b[^.]*\bdoes\s?n?o?t?'?t?\s*exist/i, + /\bTable\b[^.]*\b(?:does\s+not|doesn'?t)\s+exist/i,apps/webapp/app/services/dashboardAgentBodyCap.server.ts-34-39 (1)
34-39: 🩺 Stability & Availability | 🟡 Minor | ⚡ Quick winDestroy the request on the declared-oversize path too.
The streaming path tears the request down after the refusal reaches the wire (line 49). The
content-lengthpath returns immediately and leaves the request stream open and unread. The client can keep sending the whole oversize body, and nothing consumes or aborts it.Apply the same teardown to both refusal paths.
🛡️ Proposed fix
export function capRequestBody(req: Request, res: Response, limit: number): void { const declared = Number.parseInt(req.headers["content-length"] ?? "", 10); if (Number.isFinite(declared) && declared > limit) { refuse(res); + // Torn down only once the refusal is on the wire, or the client never reads it. + res.once("finish", () => req.destroy()); return; }apps/webapp/test/reportsApiRoute.test.ts-160-165 (1)
160-165: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winThe format tests assert on a bare
[instead of theESCconstant. The file definesESCat Line 19 as the ANSI CSI introducer, but both format assertions test for the[character alone. A bare[also appears in markdown link syntax and in bracketed values, so these assertions are imprecise in both directions.
apps/webapp/test/reportsApiRoute.test.ts#L160-L165: replaceexpect(await response.text()).toContain("[")withtoContain(ESC).apps/webapp/test/reportsApiRoute.test.ts#L156-L157: remove theexpect(body).not.toContain("[")line; the precedingnot.toContain(ESC)already proves the markdown render carries no escape sequence.apps/webapp/test/apiAuthActorClaim.test.ts-94-108 (1)
94-108: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winThree new tests assert against test-constructed values instead of production output. In each case the assertion input is built by the test rather than read from the code under test, so the test still passes if the delegated-token path regresses. Bind each assertion to the value the production code returns.
apps/webapp/test/apiAuthActorClaim.test.ts#L94-L108: build the ability from the scopes on the authentication result, not fromforged.scopes, so a regression that mergesact.scopesinto the effective scopes fails the test.apps/webapp/test/dashboardAgentDelegatedScopeCeiling.test.ts#L19-L42: passresult.claimsfromauthenticateUserActorintoclampUserActorScopesinstead of the hand-built{ userId, client, cap }object.apps/webapp/test/userActorEnvironmentScopeRouteBuilder.test.ts#L172-L185: target the matching project and assert a 200 with the claimed environment, so only a real claim recovery satisfies the test.apps/webapp/test/userActorTokenClaimsAndScopes.test.ts-89-109 (1)
89-109: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winReset
ctx.omitClaimsin anafterEachhook.
ctx.omitClaimsis module-level mutable state. The test on line 100 sets it totrueand resets it on line 107. If the awaited call on lines 103-105 rejects, line 107 never runs and the flag staystrue. The fourpostgresTestcases below never set the flag, so they would then run against a controller that omits claims, and the failures would point away from the real cause.💚 Suggested change
+import { afterEach, expect, it, vi } from "vitest"; + +afterEach(() => { + ctx.omitClaims = false; +}); + it("recovers the claim when the RBAC controller doesn't return it", async () => { ctx.omitClaims = true; const result = await authenticateApiRequestWithPersonalAccessToken( bearer(await token({ environmentId: "env_claimed" })) ); - ctx.omitClaims = false; expect(result?.userActor?.environmentId).toBe("env_claimed"); });Merge the
afterEachinto the existing import on line 11.apps/webapp/app/services/dashboardAgentEvalRetention.server.ts-43-55 (1)
43-55: 🩺 Stability & Availability | 🟡 Minor | ⚡ Quick winNo change needed for the retention sweep cadence.
The sweep runs every 5 minutes and drains the backlog over multiple runs; the 500-row cap is documented as part of a bounded per-run statement.
♻️ Preserve the original failure on the rethrow
- } catch (error) { - result.failed++; - logger.error("Dashboard agent turn-eval retention failed", { error }); - } - - if (result.failed > 0) { - throw new Error("The dashboard agent turn-eval retention pass failed"); - } + } catch (error) { + result.failed++; + logger.error("Dashboard agent turn-eval retention failed", { error }); + throw new Error("The dashboard agent turn-eval retention pass failed", { cause: error }); + }internal-packages/dashboard-agent/src/dashboard-agent.eval.ts-1039-1045 (1)
1039-1045: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winThe
identityClaimregex rejects a correctly hedged answer.The comment on Lines 1039-1040 states that naming the phrase in order to deny it is the hedge the test wants. The regex does not implement that. It matches the phrase wherever it appears, including inside a denial. An answer such as "I cannot confirm this is the exact deployed code" matches and fails the assertion, even though it is the behavior the case is checking for.
The negative lookahead cases that do pass, such as "is not necessarily the exact deployed code", pass by accident: the optional literal groups happen not to absorb the intervening words.
Since
judgeClaimon Lines 1047-1054 already evaluates this claim in full, the regex adds a flake source without adding coverage. Consider removing the twonot.toMatchassertions and keeping the judge verdict plus thesnapshot|not provably|may differcheck.💚 Proposed fix
- // The forbidden claim: asserting the source it read IS what ran. Match the assertion, - // not the words: naming the phrase in order to deny it is the hedge we want. - const identityClaim = - /(is|was|matches|reflects) (exactly )?(the )?(exact )?deployed code\b|is (exactly )?what (actually )?ran\b/i; - expect(answer).not.toMatch(identityClaim); - expect(card).not.toMatch(identityClaim); + // The hedge must be present. Whether the answer wrongly asserts identity is left to + // the judge below: a regex cannot tell an assertion from a denial of the same phrase. expect(`${answer}\n${card}`).toMatch(/snapshot|not provably|may differ/i);apps/webapp/app/utils/cspImageOrigins.ts-104-108 (1)
104-108: 🔒 Security & Privacy | 🟡 Minor | ⚡ Quick winMatch
img-srccase-insensitively.CSP directive names are ASCII case-insensitive. The regex on Line 106 is case-sensitive, so an existing policy that spells the directive
Img-SrcorIMG-SRCis not detected.withImgSrcthen appends a secondimg-srcdirective. A duplicate directive is ignored by the browser, so the route's directive still wins, but the emitted header is malformed and browsers log a warning.The companion scanner in
apps/webapp/test/routeCspImgSrc.test.ts(Line 53) already uses theiflag, so the two disagree today.🔒️ Proposed fix
export function withImgSrc(existing: string | null | undefined, directive: string): string { if (!existing) return directive; - if (/(^|;)\s*img-src\s/.test(existing)) return existing; + if (/(^|;)\s*img-src\s/i.test(existing)) return existing; return `${existing.replace(/;\s*$/, "")}; ${directive}`; }internal-packages/dashboard-agent/src/agent-runtime.ts-324-340 (1)
324-340: 🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win
isBadInputtreats an array as a valid tool input.The check is
typeof input !== "object" || input === null.typeof [] === "object", so an array input passes as valid and is left in the replayed history. The Anthropic API rejects a non-object fortool_use.input, and an array fails the same way an empty string does. The turn then fails with the exact error this function exists to prevent.An empty string and
nullare the common cases, so this is a narrow gap, but closing it is one predicate.🛡️ Proposed fix
const isBadInput = (part: unknown) => typeof part === "object" && part !== null && (part as { type?: string }).type === "tool-call" && (typeof (part as { input?: unknown }).input !== "object" || - (part as { input?: unknown }).input === null); + (part as { input?: unknown }).input === null || + Array.isArray((part as { input?: unknown }).input));internal-packages/dashboard-agent-contracts/src/watch.ts-21-25 (1)
21-25: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winReject an empty
note.
noteis documented as the reason shown to the user when the watch fires.z.string()accepts"", so a caller can create a watch whose fired card explains nothing. The schema already rejects a missingnote; add a minimum length so it also rejects a blank one.Consider trimming as well, so
" "is rejected too.🛡️ Proposed fix
export const watchCommonSchema = z.object({ maxHours: z.number().positive().max(WATCH_MAX_HOURS), /** Why this watch exists, in the user's terms. Shown when it fires. */ - note: z.string(), + note: z.string().trim().min(1), });internal-packages/dashboard-agent/src/tool-docs.ts-59-66 (1)
59-66: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winThe separator length is not counted against
DOCS_RESULT_MAX_CHARS.
usedaccumulates onlyentry.length. Line 66 joins the entries with"\n\n---\n\n", which adds 8 characters between each pair. With the maximum of 5 entries the returned string can exceed the cap by up to 32 characters.The overshoot is negligible for token cost, but it breaks the invariant the test asserts.
apps/webapp-style byte caps aside,tool-docs.test.tsLine 29 assertsformatted.length <= DOCS_RESULT_MAX_CHARS. That assertion holds today only because the byte cap never binds in that case. Once a case does bind the cap, the test can fail against correct-looking code.Count the separator when the entry is not the first.
🐛 Proposed fix
+const RESULT_SEPARATOR = "\n\n---\n\n"; + export function formatDocsResults(parts: string[]): string { const rendered: string[] = []; let used = 0; @@ // Stop on the overall cap rather than truncating mid-excerpt: a half-quoted // sentence is worse than one fewer result. - if (used + entry.length > DOCS_RESULT_MAX_CHARS) break; + const cost = entry.length + (rendered.length > 0 ? RESULT_SEPARATOR.length : 0); + if (used + cost > DOCS_RESULT_MAX_CHARS) break; rendered.push(entry); - used += entry.length; + used += cost; } - return rendered.join("\n\n---\n\n"); + return rendered.join(RESULT_SEPARATOR); }internal-packages/dashboard-agent/src/tool-docs.test.ts-24-33 (1)
24-33: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winThis test never exercises the
DOCS_RESULT_MAX_CHARSbreak.The case is named for the byte cap, but the count cap is what limits the output.
formatDocsResultsslices toMAX_DOC_RESULTS(5) first. Each of the 5 bodies is truncated toDOC_EXCERPT_MAX_CHARS(1200) plus the suffix and the three header lines, so the total is roughly 6.5k against a 7,000 cap. Theif (used + entry.length > DOCS_RESULT_MAX_CHARS) break;branch on Line 61 oftool-docs.tsis never reached.
expect(formatted.split("\n---\n").length).toBeLessThanOrEqual(5)passes at exactly 5, which is whatMAX_DOC_RESULTSguarantees on its own.Add a case where the byte cap binds before the count cap, so a regression in the cap logic fails a test.
💚 Proposed additional case
it("stays inside the cap however much the endpoint returns", () => { const parts = Array.from({ length: 12 }, (_, i) => part({ title: `Result ${i}`, page: `page-${i}`, body: "x".repeat(9_000) }) ); const formatted = formatDocsResults(parts); expect(formatted.length).toBeLessThanOrEqual(DOCS_RESULT_MAX_CHARS); // A handful of results, each an excerpt rather than the whole section. expect(formatted.split("\n---\n").length).toBeLessThanOrEqual(5); expect(formatted).toContain("[excerpt — the rest is on the page]"); }); + + it("stops on the byte cap before it runs out of results", () => { + // A long title pushes each entry over 1/5th of the cap, so the break fires + // before MAX_DOC_RESULTS does. + const parts = Array.from({ length: 5 }, (_, i) => + part({ title: "T".repeat(1_500), page: `page-${i}`, body: "x".repeat(9_000) }) + ); + const formatted = formatDocsResults(parts); + expect(formatted.length).toBeLessThanOrEqual(DOCS_RESULT_MAX_CHARS); + expect(formatted.split("\n---\n").length).toBeLessThan(5); + });internal-packages/dashboard-agent-contracts/src/watch.ts-245-265 (1)
245-265: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winDerive the failed disposition list from
TaskRunStatus.
WATCH_FAILED_RUN_STATUSESis a hardcoded copy of the Prisma enum’s terminal statuses. If the source enum adds a new terminal failure status,watchRunDisposition()silently returns"unknown", andresolveWatchResult()reports a failed watch result as neutral. Keep this list tied to the shared status type or generated from the schema so new statuses are caught at typecheck time.internal-packages/dashboard-agent/src/dashboard-agent.eval.ts-499-519 (1)
499-519: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winClassify exhausted AI SDK retries as provider failures.
When the AI SDK internal retries are exhausted, it can throw an
AI_RetryError, butgoldenCaseonly treatsAPICallErrornames as infrastructure. That path spends a behavior retry instead of retrying provider failure. Import the SDK retry error guard/instance check, or classify provider errors by theirAI_class/name family/status code, not onlyAPICallError.internal-packages/dashboard-agent/src/dashboard-agent.test.ts-104-119 (1)
104-119: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winWait for the second turn to settle before asserting the title count.
The other turn-completion tests in this file wait a tick, because
setChatTitleIfDefaultis written after the turn-complete chunk. This test asserts that the count is exactly 1 without waiting. If a second title write were queued, the assertion could run before that write lands, and the test would pass for the wrong reason.💚 Proposed fix
await harness.sendMessage(userMessage("first question")); await harness.sendMessage(userMessage("second question")); + // Give a second title write a chance to land, so the count is a real "once". + await new Promise((r) => setTimeout(r, 30)); expect(calls.setChatTitleIfDefault).toHaveLength(1);internal-packages/dashboard-agent-db/drizzle/meta/0002_snapshot.json-1-6 (1)
1-6: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winRun the formatter to clear the failing code-quality job.
Both
code-qualitypipeline jobs fail with "formatting check failed. Run 'pnpm exec oxfmt .' to fix formatting." The failure carries no file or line, so it may originate in any file in this PR rather than in this generated snapshot.Run
pnpm exec oxfmt .and commit the result. Ifoxfmtreformats this drizzle-generated snapshot, excludeinternal-packages/dashboard-agent-db/drizzle/meta/**from the formatter instead, so the nextdrizzle-kit generatedoes not reintroduce the diff.Source: Pipeline failures
internal-packages/dashboard-agent-db/src/queries.ts-454-491 (1)
454-491: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winThe doc comment overstates the idempotency guarantee under concurrency.
Lines 455-456 state that a repeat of the same id writes "nothing at all — not the row, not the position, not the chat's timestamps". That holds for the sequential redelivery the
not existsguard catches, which is the case the test on lines 152-157 ofapps/webapp/test/dashboardAgentTranscriptStore.test.tscovers.It does not hold for the concurrent case the next paragraph relies on
on conflict do nothingto settle. When two callers both pass thenot existscheck, the losing statement has already executed thereservedCTE:next_message_positionis incremented andlast_message_atandupdated_atare set. Only the insert is discarded. The function correctly returnsfalse, but a position is consumed and the chat timestamps move.The consequences are benign —
positiononly has to be unique and ordered, and gaps are expected. Narrow the comment so a later reader does not build on a guarantee the statement does not provide.📝 Proposed comment fix
/** - * Append one message, exactly once. A repeat of the same id writes nothing at all — not - * the row, not the position, not the chat's timestamps — and says so by returning false. + * Append one message, exactly once. A redelivery the `not exists` guard sees writes + * nothing at all — not the row, not the position, not the chat's timestamps — and says + * so by returning false. * * Reserve-and-insert is one statement so a concurrent append can neither take the same * position nor be lost, and `on conflict do nothing` is what settles the race two - * callers that both saw the message missing would otherwise lose. + * callers that both saw the message missing would otherwise lose. That loser still + * spends its reserved position and bumps the chat's timestamps; only the row is + * discarded. Positions are unique and ordered, never contiguous, so the gap is inert. */internal-packages/dashboard-agent-db/src/watch-queries.ts-443-460 (1)
443-460: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
spec.noteis guarded in one mapper and not in the other.Line 451 assigns
note: row.spec.notedirectly intoActiveWatchSummary.note, which is declaredstringon line 398.toUnreadWatchWakereads the same field from the same column on line 609 and guards it:row.spec.note?.trim() || row.identity.
specis ajsonbcolumn with no database-level shape check, andPersistedWatchSpecis only a TypeScript view of it. A row written beforenoteexisted, or with a blank note, therefore reaches the wake banner asundefinedthrough this path while the other path falls back toidentity.Apply the same fallback in both mappers.
🐛 Proposed fix
- note: row.spec.note, + note: row.spec.note?.trim() || row.identity,internal-packages/dashboard-agent-contracts/src/intent.ts-12-12 (1)
12-12: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winRequire a non-empty
promptforaskintents.
agentIntentSchemaaccepts{ kind: "ask", prompt: "" }. The lenient variants inblocks.ts(chartActionIntentSchema,actionIntentSchema) both usez.string().min(1).investigationActionSchemavalidates withagentIntentSchema, so an executor-built button can carry an empty prompt and send an empty message on click. Align the constraint.🛡️ Proposed fix
- z.object({ kind: z.literal("ask"), prompt: z.string() }), + z.object({ kind: z.literal("ask"), prompt: z.string().min(1) }),
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: a4f8f415-64ba-4b82-a190-87095e4c1724
⛔ Files ignored due to path filters (3)
apps/webapp/test/__snapshots__/reportRenderParity.test.ts.snapis excluded by!**/*.snapinternal-packages/dashboard-agent/src/__snapshots__/prompt-prefix.test.ts.snapis excluded by!**/*.snappnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (189)
.changeset/report-json-and-period-units.md.gitignore.server-changes/dashboard-agent.mdapps/webapp/.gitignoreapps/webapp/app/components/AskAI.tsxapps/webapp/app/components/dashboard-agent/message-limits.test.tsapps/webapp/app/components/dashboard-agent/message-limits.tsapps/webapp/app/components/dashboard-agent/resolve-uris.test.tsapps/webapp/app/components/dashboard-agent/resolve-uris.tsapps/webapp/app/components/metrics/MiniLineChart.tsxapps/webapp/app/components/navigation/SideMenuItem.tsxapps/webapp/app/components/primitives/AgentDotMatrix.tsxapps/webapp/app/components/primitives/Buttons.tsxapps/webapp/app/components/primitives/Popover.tsxapps/webapp/app/components/primitives/Spinner.tsxapps/webapp/app/components/primitives/TextLink.tsxapps/webapp/app/components/primitives/Toast.tsxapps/webapp/app/components/queues/queue-thresholds.tsapps/webapp/app/components/runs/v3/agent/AgentMessageView.tsxapps/webapp/app/entry.server.tsxapps/webapp/app/env.server.tsapps/webapp/app/hooks/useThemeMode.tsapps/webapp/app/presenters/v3/reports/ReportPresenter.server.tsapps/webapp/app/presenters/v3/reports/health/execution.tsapps/webapp/app/presenters/v3/reports/health/flow.tsapps/webapp/app/presenters/v3/reports/health/health-core.tsapps/webapp/app/presenters/v3/reports/health/health-data.tsapps/webapp/app/presenters/v3/reports/health/health-messages.tsapps/webapp/app/presenters/v3/reports/health/health.tsapps/webapp/app/presenters/v3/reports/health/liveness.tsapps/webapp/app/presenters/v3/reports/renderMarkdown.tsapps/webapp/app/presenters/v3/reports/report-layout.tsapps/webapp/app/presenters/v3/reports/report-message-catalogs.tsapps/webapp/app/presenters/v3/reports/report-messages.tsapps/webapp/app/presenters/v3/reports/report-registry.tsapps/webapp/app/presenters/v3/reports/report-view-model.tsapps/webapp/app/presenters/v3/reports/reportsApi.server.tsapps/webapp/app/presenters/v3/waitingRun/waitingRunDiagnosis.server.tsapps/webapp/app/presenters/v3/waitingRun/waitingRunDiagnosis.tsapps/webapp/app/root.tsxapps/webapp/app/routes/_app.orgs.$organizationSlug.settings.private-connections._index/route.tsxapps/webapp/app/routes/_app.orgs.$organizationSlug.settings.private-connections.new/route.tsxapps/webapp/app/routes/account.tokens/route.tsxapps/webapp/app/routes/api.v1.dashboard-agent.eval-policy.tsapps/webapp/app/routes/api.v1.projects.$projectRef.$env.jwt.tsapps/webapp/app/routes/api.v1.projects.$projectRef.$env.repo.snapshot.tsapps/webapp/app/routes/api.v1.projects.$projectRef.$env.runs.$runId.commit.tsapps/webapp/app/routes/api.v1.projects.$projectRef.$env.runs.$runId.waiting.tsapps/webapp/app/routes/api.v1.projects.$projectRef.$env.workers.$tagName.tsapps/webapp/app/routes/api.v1.projects.$projectRef.environments.tsapps/webapp/app/routes/api.v1.projects.$projectRef.runs.tsapps/webapp/app/routes/api.v1.query.tsapps/webapp/app/routes/api.v1.queues.$queueParam.metrics.tsapps/webapp/app/routes/api.v1.reports.$key.tsapps/webapp/app/routes/projects.$projectRef.ai-help.tsapps/webapp/app/routes/resources.orgs.$organizationSlug.projects.$projectParam.env.$envParam.dashboard-agent.in.$.tsapps/webapp/app/routes/resources.orgs.$organizationSlug.projects.$projectParam.env.$envParam.dashboard-agent.tsapps/webapp/app/routes/storybook.ai-agent/route.tsxapps/webapp/app/routes/storybook.buttons/route.tsxapps/webapp/app/services/apiAuth.server.tsapps/webapp/app/services/dashboardAgent.server.tsapps/webapp/app/services/dashboardAgentBodyCap.server.tsapps/webapp/app/services/dashboardAgentEvalPolicy.server.tsapps/webapp/app/services/dashboardAgentEvalRetention.server.tsapps/webapp/app/services/dashboardAgentHeadStart.server.tsapps/webapp/app/services/dashboardAgentInvestigationSweep.server.tsapps/webapp/app/services/personalAccessToken.server.tsapps/webapp/app/services/queryService.server.tsapps/webapp/app/services/resolveTriggerUri.server.tsapps/webapp/app/services/routeBuilders/apiBuilder.server.tsapps/webapp/app/services/tenantContext.server.tsapps/webapp/app/services/uatRoutePreamble.server.tsapps/webapp/app/services/userActorEnvironment.server.tsapps/webapp/app/tailwind.cssapps/webapp/app/utils/boundedRequestBody.server.test.tsapps/webapp/app/utils/boundedRequestBody.server.tsapps/webapp/app/utils/cspImageOrigins.test.tsapps/webapp/app/utils/cspImageOrigins.tsapps/webapp/app/v3/canAccessDashboardAgent.server.tsapps/webapp/app/v3/commonWorker.server.tsapps/webapp/app/v3/featureFlags.tsapps/webapp/app/v3/queryScope.tsapps/webapp/app/v3/services/alerts/deliverAlert.server.tsapps/webapp/package.jsonapps/webapp/seed-queue-metrics.mtsapps/webapp/server.tsapps/webapp/test/apiAuthActorClaim.test.tsapps/webapp/test/dashboardAgentBodyCap.test.tsapps/webapp/test/dashboardAgentClientMetadata.test.tsapps/webapp/test/dashboardAgentDelegatedScopeCeiling.test.tsapps/webapp/test/dashboardAgentEvalPolicyAuth.test.tsapps/webapp/test/dashboardAgentEvalRetention.test.tsapps/webapp/test/dashboardAgentHeadStart.test.tsapps/webapp/test/dashboardAgentImageCsp.test.tsapps/webapp/test/dashboardAgentInvestigationSweep.test.tsapps/webapp/test/dashboardAgentLegacyMessagesColumn.test.tsapps/webapp/test/dashboardAgentRoutes.test.tsapps/webapp/test/dashboardAgentTranscriptStore.test.tsapps/webapp/test/envJwtActorClaim.test.tsapps/webapp/test/queryScope.test.tsapps/webapp/test/rbacFallbackBranch.test.tsapps/webapp/test/reportHealth.test.tsapps/webapp/test/reportHealthData.test.tsapps/webapp/test/reportPresenter.test.tsapps/webapp/test/reportsApiRoute.test.tsapps/webapp/test/resolveTriggerUri.test.tsapps/webapp/test/routeCspImgSrc.test.tsapps/webapp/test/tenantContextFromAuthEnvironment.test.tsapps/webapp/test/uatEnvironmentClaim.test.tsapps/webapp/test/userActorEnvironmentScopeRouteBuilder.test.tsapps/webapp/test/userActorProjectWideScope.test.tsapps/webapp/test/userActorTokenClaimsAndScopes.test.tsapps/webapp/test/waitingRunDiagnosis.test.tsapps/webapp/vite.config.tsapps/webapp/vitest.config.tsdocs/self-hosting/env/webapp.mdxinternal-packages/dashboard-agent-contracts/package.jsoninternal-packages/dashboard-agent-contracts/src/blocks.test.tsinternal-packages/dashboard-agent-contracts/src/blocks.tsinternal-packages/dashboard-agent-contracts/src/contracts.test.tsinternal-packages/dashboard-agent-contracts/src/evidence.tsinternal-packages/dashboard-agent-contracts/src/index.tsinternal-packages/dashboard-agent-contracts/src/intent.tsinternal-packages/dashboard-agent-contracts/src/page-context.tsinternal-packages/dashboard-agent-contracts/src/run-filters.tsinternal-packages/dashboard-agent-contracts/src/suggested-prompts.tsinternal-packages/dashboard-agent-contracts/src/trigger-uri.test.tsinternal-packages/dashboard-agent-contracts/src/trigger-uri.tsinternal-packages/dashboard-agent-contracts/src/watch.test.tsinternal-packages/dashboard-agent-contracts/src/watch.tsinternal-packages/dashboard-agent-contracts/tsconfig.jsoninternal-packages/dashboard-agent-contracts/vitest.config.tsinternal-packages/dashboard-agent-db/README.mdinternal-packages/dashboard-agent-db/drizzle/0002_watches_and_chat_messages.sqlinternal-packages/dashboard-agent-db/drizzle/meta/0002_snapshot.jsoninternal-packages/dashboard-agent-db/drizzle/meta/_journal.jsoninternal-packages/dashboard-agent-db/package.jsoninternal-packages/dashboard-agent-db/src/ids.tsinternal-packages/dashboard-agent-db/src/index.tsinternal-packages/dashboard-agent-db/src/internal.tsinternal-packages/dashboard-agent-db/src/queries.tsinternal-packages/dashboard-agent-db/src/schema-base.tsinternal-packages/dashboard-agent-db/src/schema.tsinternal-packages/dashboard-agent-db/src/watch-queries.tsinternal-packages/dashboard-agent-db/src/watch-schema.tsinternal-packages/dashboard-agent/README.mdinternal-packages/dashboard-agent/package.jsoninternal-packages/dashboard-agent/src/agent-runtime.tsinternal-packages/dashboard-agent/src/cache-breakpoint.test.tsinternal-packages/dashboard-agent/src/compaction.test.tsinternal-packages/dashboard-agent/src/compaction.tsinternal-packages/dashboard-agent/src/dashboard-agent.eval.tsinternal-packages/dashboard-agent/src/dashboard-agent.test.tsinternal-packages/dashboard-agent/src/dashboard-agent.tsinternal-packages/dashboard-agent/src/eval-error-category.test.tsinternal-packages/dashboard-agent/src/eval-policy.tsinternal-packages/dashboard-agent/src/eval-redaction.test.tsinternal-packages/dashboard-agent/src/eval-turn.tsinternal-packages/dashboard-agent/src/index.tsinternal-packages/dashboard-agent/src/prompt-prefix.test.tsinternal-packages/dashboard-agent/src/prompt-prefix.tsinternal-packages/dashboard-agent/src/repo-tools.test.tsinternal-packages/dashboard-agent/src/repo-tools.tsinternal-packages/dashboard-agent/src/step-cache.test.tsinternal-packages/dashboard-agent/src/step-cache.tsinternal-packages/dashboard-agent/src/test-support.tsinternal-packages/dashboard-agent/src/tool-api-client.tsinternal-packages/dashboard-agent/src/tool-api.tsinternal-packages/dashboard-agent/src/tool-context.tsinternal-packages/dashboard-agent/src/tool-curation.tsinternal-packages/dashboard-agent/src/tool-docs.test.tsinternal-packages/dashboard-agent/src/tool-docs.tsinternal-packages/dashboard-agent/src/tool-evidence.tsinternal-packages/dashboard-agent/src/tool-investigations.tsinternal-packages/dashboard-agent/src/tool-navigation.tsinternal-packages/dashboard-agent/src/tool-schemas.tsinternal-packages/dashboard-agent/src/tool-source-ledger.tsinternal-packages/dashboard-agent/src/tools.tsinternal-packages/dashboard-agent/vitest.eval.config.tsinternal-packages/rbac/src/fallback.tsinternal-packages/tsql/src/read-only.test.tspackages/cli-v3/src/apiClient.tspackages/cli-v3/src/mcp/prompts.test.tspackages/cli-v3/src/mcp/prompts.tspackages/cli-v3/src/mcp/schemas.tspackages/core/src/v3/apiClient/index.tspackages/core/src/v3/schemas/index.tspackages/core/src/v3/schemas/reports.tspackages/plugins/src/rbac.ts
💤 Files with no reviewable changes (1)
- apps/webapp/app/presenters/v3/reports/report-message-catalogs.ts
🚧 Files skipped from review as they are similar to previous changes (29)
- internal-packages/dashboard-agent/vitest.eval.config.ts
- internal-packages/dashboard-agent-db/src/index.ts
- apps/webapp/app/routes/api.v1.projects.$projectRef.$env.runs.$runId.commit.ts
- apps/webapp/app/routes/account.tokens/route.tsx
- internal-packages/dashboard-agent-db/src/ids.ts
- internal-packages/dashboard-agent-contracts/tsconfig.json
- apps/webapp/vitest.config.ts
- apps/webapp/app/routes/api.v1.projects.$projectRef.$env.workers.$tagName.ts
- apps/webapp/test/dashboardAgentHeadStart.test.ts
- internal-packages/dashboard-agent-contracts/src/index.ts
- apps/webapp/app/components/runs/v3/agent/AgentMessageView.tsx
- internal-packages/dashboard-agent-contracts/src/suggested-prompts.ts
- apps/webapp/app/routes/_app.orgs.$organizationSlug.settings.private-connections.new/route.tsx
- apps/webapp/.gitignore
- apps/webapp/app/routes/api.v1.queues.$queueParam.metrics.ts
- apps/webapp/test/waitingRunDiagnosis.test.ts
- apps/webapp/test/dashboardAgentRoutes.test.ts
- internal-packages/dashboard-agent-db/package.json
- apps/webapp/app/v3/featureFlags.ts
- internal-packages/dashboard-agent/package.json
- internal-packages/dashboard-agent-contracts/package.json
- internal-packages/dashboard-agent-contracts/vitest.config.ts
- apps/webapp/app/routes/api.v1.projects.$projectRef.$env.runs.$runId.waiting.ts
- apps/webapp/app/presenters/v3/waitingRun/waitingRunDiagnosis.ts
- apps/webapp/app/services/uatRoutePreamble.server.ts
- internal-packages/dashboard-agent-contracts/src/trigger-uri.ts
- apps/webapp/app/components/metrics/MiniLineChart.tsx
- apps/webapp/seed-queue-metrics.mts
- internal-packages/dashboard-agent/src/tool-schemas.ts
| // Stuck investigation cards and turn-eval retention. | ||
| "dashboardAgent.maintenance": { | ||
| schema: CronSchema, | ||
| visibilityTimeoutMs: 60_000 * 5, | ||
| cron: "*/5 * * * *", | ||
| jitterInMs: 30_000, | ||
| retry: { | ||
| maxAttempts: 1, | ||
| }, | ||
| }, |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
Confirm the visibility timeout exceeds the worst-case sweep duration.
visibilityTimeoutMs is 300000 and the cron interval is also 5 minutes. If either sweep runs longer than 5 minutes, the message becomes visible again while the first execution is still running. Two maintenance runs can then delete or update the same investigation and turn-eval rows at the same time. maxAttempts: 1 does not prevent this, because redelivery after a visibility timeout is a separate delivery.
Set the visibility timeout above the expected worst case, or confirm the sweeps are bounded and idempotent.
🔧 Suggested change
"dashboardAgent.maintenance": {
schema: CronSchema,
- visibilityTimeoutMs: 60_000 * 5,
+ // Above the 5 minute cron interval, so a slow sweep is not redelivered while it runs.
+ visibilityTimeoutMs: 60_000 * 10,
cron: "*/5 * * * *",📝 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.
| // Stuck investigation cards and turn-eval retention. | |
| "dashboardAgent.maintenance": { | |
| schema: CronSchema, | |
| visibilityTimeoutMs: 60_000 * 5, | |
| cron: "*/5 * * * *", | |
| jitterInMs: 30_000, | |
| retry: { | |
| maxAttempts: 1, | |
| }, | |
| }, | |
| // Stuck investigation cards and turn-eval retention. | |
| "dashboardAgent.maintenance": { | |
| schema: CronSchema, | |
| // Above the 5 minute cron interval, so a slow sweep is not redelivered while it runs. | |
| visibilityTimeoutMs: 60_000 * 10, | |
| cron: "*/5 * * * *", | |
| jitterInMs: 30_000, | |
| retry: { | |
| maxAttempts: 1, | |
| }, | |
| }, |
| /** A public access token is environment-bound; every other bearer credential isn't. */ | ||
| export function queryScopeCeilingFor(authenticationType: string): QueryScopeCeiling { | ||
| return authenticationType === "PUBLIC_JWT" ? "environment" : "unbounded"; | ||
| } |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Locate the authentication type union and every caller of queryScopeCeilingFor.
set -uo pipefail
rg -nP --type=ts -C 4 '\bqueryScopeCeilingFor\s*\('
rg -nP --type=ts -C 6 '"PUBLIC_JWT"' -g '!**/*.test.ts'
rg -nP --type=ts -C 4 'type\s+\w*Authentication\w*\s*='Repository: triggerdotdev/trigger.dev
Length of output: 163
🏁 Script executed:
#!/bin/bash
set -uo pipefail
echo "Tracked files matching queryScope.ts:"
git ls-files | rg 'apps/webapp/app/v3/queryScope\.ts$|queryScope'
echo
echo "Search helper (including all files, excluding test files for caller context):"
rg -n -C 4 'queryScopeCeilingFor' || true
echo
echo "Search PUBLIC_JWT (excluding tests):"
rg -n -C 6 '"PUBLIC_JWT"|PUBLIC_JWT' --glob '!**/*.test.ts' --glob '!**/*.spec.ts' || true
echo
echo "Search authentication type declarations:"
rg -n -C 4 'Authentication|authentication' --type ts --type tsx | head -n 240 || trueRepository: triggerdotdev/trigger.dev
Length of output: 349
🏁 Script executed:
#!/bin/bash
set -eo pipefail
echo "Tracked files matching queryScope.ts:"
git ls-files | rg 'apps/webapp/app/v3/queryScope\.ts$|queryScope' || true
echo
echo "Helper contents:"
cat -n apps/webapp/app/v3/queryScope.ts || true
echo
echo "Tests mentioning queryScopeCeilingFor or queryScope:"
rg -n -C 5 'queryScopeCeilingFor|queryScope|PUBLIC_JWT' apps/webapp/test --glob '*.ts' --glob '*.tsx' || true
echo
echo "Repo-wide caller search:"
rg -n -C 5 'queryScopeCeilingFor' apps/webapp packages core 2>/dev/null || true
echo
echo "Repo-wide PUBLIC_JWT search (excluding tests):"
rg -n -C 6 'PUBLIC_JWT|PUBLIC-JWT' --glob '!**/*.test.ts' --glob '!**/*.spec.ts' . || true
echo
echo "Potential authenticator/authentication type declarations (TS files only):"
rg -n -C 5 'Authentication|authenticationType|accessTokenType|Auth\s*=\s*{|\{\s*"PUBLIC_JWT"|type "PUBLIC_JWT"|AuthenticationType\??:' --type ts --type tsx . | head -n 300 || trueRepository: triggerdotdev/trigger.dev
Length of output: 22074
🏁 Script executed:
#!/bin/bash
set -eo pipefail
echo "api v1 query route relevant section:"
cat -n apps/webapp/app/routes/api.v1.query.ts | sed -n '1,90p'
echo
echo "apiAuth relevant type declaration and helper:"
cat -n apps/webapp/app/services/apiAuth.server.ts | sed -n '60,80p;370,410p'Repository: triggerdotdev/trigger.dev
Length of output: 6674
Reuse the API authentication type union for queryScopeCeilingFor.
authentication.type is "PUBLIC" | "PRIVATE" | "PUBLIC_JWT", but this helper accepts string and returns "unbounded" for anything that is not exactly "PUBLIC_JJWT". Rename the union to one shared constant or import the exact union; this keeps the public query credential as the only environment-bound token and adds a compile-time error if "PUBLIC_JWT" is renamed.
| "cadence_minutes" integer GENERATED ALWAYS AS (((spec ->> 'checkEveryMinutes')::int)) STORED | ||
| ); | ||
| --> statement-breakpoint | ||
| ALTER TABLE "trigger_dashboard_agent"."chats" DROP COLUMN IF EXISTS "messages"; |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🔴 Critical | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Look for a backfill from chats.messages into chat_messages, and for remaining readers of the dropped column.
set -euo pipefail
# Any migration that copies the legacy column.
fd -t f -e sql . internal-packages/dashboard-agent-db/drizzle --exec rg -n -C 5 'messages' {}
# Code that still reads or writes chats.messages.
rg -n -C 4 'chats\.messages|legacyMessages|\bmessages\b.*jsonb' --type=ts internal-packages/dashboard-agent-db apps/webapp
# The legacy-column test, which may document the intended behavior.
fd -t f 'dashboardAgentLegacyMessagesColumn.test.ts' --exec cat -n {}Repository: triggerdotdev/trigger.dev
Length of output: 2513
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== migration file =="
cat -n internal-packages/dashboard-agent-db/drizzle/0002_watches_and_chat_messages.sql
echo
echo "== relevant files =="
git ls-files | rg 'internal-packages/dashboard-agent-db/drizzle/(0001|0002)|dashboardAgentLegacyMessagesColumn\.test\.ts|drizzle\.config|schema|tables|chat' | head -200
echo
echo "== schema references for drops/backfills/messages ==="
rg -n -C 4 'DROP COLUMN|backfill|ALTER TABLE .*chat_messages|backfill|chats.*messages|chat_messages|legacyMessages|messages.*jsonb|INSERT INTO .*chat_messages|SELECT .*messages' -S .Repository: triggerdotdev/trigger.dev
Length of output: 50382
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== dashboardAgentLegacyMessagesColumn.test.ts =="
cat -n apps/webapp/test/dashboardAgentLegacyMessagesColumn.test.ts
echo
echo "== messages references in dashboard agent code/services =="
rg -n -C 3 'chats\.messages|messages\]|messages\b.*jsonb|chat_messages|legacyMessages|ChatAgent|messages' internal-packages/dashboard-agent src packages apps/internal -g '*.ts' -g '!**/test/**' 2>/dev/null | head -400
echo
echo "== deterministic SQL structural check for backfill before drop in 0002 =="
python3 - <<'PY'
from pathlib import Path
p = Path("internal-packages/dashboard-agent-db/drizzle/0002_watches_and_chat_messages.sql")
text = p.read_text()
lines = text.splitlines()
checks = {
"has_chat_messages_table": any('CREATE TABLE "trigger_dashboard_agent"."chat_messages"' in line for line in lines),
"has_drop_messages": any('DROP COLUMN IF EXISTS "messages"' in line for line in lines),
"has_backfill_insert_into_chat_messages": any('INSERT INTO "trigger_dashboard_agent"."chat_messages"' in line or 'INSERT INTO chat_messages' in line for line in lines),
"has_select_messages": any('.messages' in line or 'messages"' in line for line in lines if 'chats' in line),
}
print("\n".join(f"{k}: {v}" for k,v in checks.items()))
if not checks["has_backfill_insert_into_chat_messages"]:
print("backfill INSERT_BEFORE_DROP: False")
print("DROP_LINE_INDEX", next((i+1 for i,l in enumerate(lines) if 'DROP COLUMN IF EXISTS "messages"' in l), None))
PYRepository: triggerdotdev/trigger.dev
Length of output: 39885
Backfill chats.messages before dropping it in 0002_watches_and_chat_messages.sql.
This migration creates chat_messages and then drops chats.messages without copying existing transcript rows. Records that still use the legacy jsonb transcript are lost at migration time; if that is intentional, document it in the PR and migration. If transcripts must be preserved, backfill into chat_messages before the drop.
| /** | ||
| * One transaction on purpose: a crash between the two halves would leave live | ||
| * watches ticking against a chat the user can no longer see. Owner-scoped. | ||
| */ | ||
| export async function softDeleteChat( | ||
| db: DashboardAgentDb, | ||
| params: { chatId: string; userId: string } | ||
| ): Promise<{ deleted: boolean; cancelledWatches: Watch[] }> { | ||
| return db.transaction(async (tx) => { | ||
| // The same lock `createWatch` takes, or a concurrent create lands an active | ||
| // watch on a chat this transaction already deleted. | ||
| await lockChatForWatches(tx, params.chatId); | ||
|
|
||
| const deleted = await tx | ||
| .update(chats) | ||
| .set({ deletedAt: sql`now()`, updatedAt: sql`now()` }) | ||
| .where(and(eq(chats.id, params.chatId), eq(chats.userId, params.userId))) | ||
| .returning({ id: chats.id }); | ||
|
|
||
| if (deleted.length === 0) return { deleted: false, cancelledWatches: [] }; | ||
|
|
||
| const cancelledWatches = await cancelActiveWatchesForChat(tx, { | ||
| chatId: params.chatId, | ||
| reason: "chat_deleted", | ||
| }); | ||
|
|
||
| return { deleted: true, cancelledWatches }; | ||
| }); | ||
| } |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
softDeleteChat is the only chat mutation left without organizationId.
This same diff added organizationId to renameChat (line 193), setChatPinned (line 222) and markChatRead (line 239). softDeleteChat still scopes on chatId and userId alone, while its doc comment on line 255 claims "Owner-scoped" and the file header on lines 27-28 states that every query touching user data must be scoped by organizationId and/or userId.
The gap is narrow but real: a user who belongs to more than one organization can delete a chat that belongs to organization A while the request is acting in organization B's context. The destructive path is also the one that cancels watches, so it is the worst place to leave the scope inconsistent with its siblings.
Add the organization filter and pass it from the callers.
🔒️ Proposed fix
export async function softDeleteChat(
db: DashboardAgentDb,
- params: { chatId: string; userId: string }
+ params: { chatId: string; userId: string; organizationId: string }
): Promise<{ deleted: boolean; cancelledWatches: Watch[] }> {
return db.transaction(async (tx) => {
// The same lock `createWatch` takes, or a concurrent create lands an active
// watch on a chat this transaction already deleted.
await lockChatForWatches(tx, params.chatId);
const deleted = await tx
.update(chats)
.set({ deletedAt: sql`now()`, updatedAt: sql`now()` })
- .where(and(eq(chats.id, params.chatId), eq(chats.userId, params.userId)))
+ .where(
+ and(
+ eq(chats.id, params.chatId),
+ eq(chats.userId, params.userId),
+ eq(chats.organizationId, params.organizationId)
+ )
+ )
.returning({ id: chats.id });📝 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.
| /** | |
| * One transaction on purpose: a crash between the two halves would leave live | |
| * watches ticking against a chat the user can no longer see. Owner-scoped. | |
| */ | |
| export async function softDeleteChat( | |
| db: DashboardAgentDb, | |
| params: { chatId: string; userId: string } | |
| ): Promise<{ deleted: boolean; cancelledWatches: Watch[] }> { | |
| return db.transaction(async (tx) => { | |
| // The same lock `createWatch` takes, or a concurrent create lands an active | |
| // watch on a chat this transaction already deleted. | |
| await lockChatForWatches(tx, params.chatId); | |
| const deleted = await tx | |
| .update(chats) | |
| .set({ deletedAt: sql`now()`, updatedAt: sql`now()` }) | |
| .where(and(eq(chats.id, params.chatId), eq(chats.userId, params.userId))) | |
| .returning({ id: chats.id }); | |
| if (deleted.length === 0) return { deleted: false, cancelledWatches: [] }; | |
| const cancelledWatches = await cancelActiveWatchesForChat(tx, { | |
| chatId: params.chatId, | |
| reason: "chat_deleted", | |
| }); | |
| return { deleted: true, cancelledWatches }; | |
| }); | |
| } | |
| /** | |
| * One transaction on purpose: a crash between the two halves would leave live | |
| * watches ticking against a chat the user can no longer see. Owner-scoped. | |
| */ | |
| export async function softDeleteChat( | |
| db: DashboardAgentDb, | |
| params: { chatId: string; userId: string; organizationId: string } | |
| ): Promise<{ deleted: boolean; cancelledWatches: Watch[] }> { | |
| return db.transaction(async (tx) => { | |
| // The same lock `createWatch` takes, or a concurrent create lands an active | |
| // watch on a chat this transaction already deleted. | |
| await lockChatForWatches(tx, params.chatId); | |
| const deleted = await tx | |
| .update(chats) | |
| .set({ deletedAt: sql`now()`, updatedAt: sql`now()` }) | |
| .where( | |
| and( | |
| eq(chats.id, params.chatId), | |
| eq(chats.userId, params.userId), | |
| eq(chats.organizationId, params.organizationId) | |
| ) | |
| ) | |
| .returning({ id: chats.id }); | |
| if (deleted.length === 0) return { deleted: false, cancelledWatches: [] }; | |
| const cancelledWatches = await cancelActiveWatchesForChat(tx, { | |
| chatId: params.chatId, | |
| reason: "chat_deleted", | |
| }); | |
| return { deleted: true, cancelledWatches }; | |
| }); | |
| } |
| it("render_view commits the chart when its query runs, validating it once", async () => { | ||
| const fetchStub = stubFetch((url, init) => { | ||
| if (url.endsWith("/jwt")) return { body: { token: "jwt_1" } }; | ||
| // The validation runs the same window the panel will render. | ||
| expect(JSON.parse(String(init?.body))).toMatchObject({ | ||
| scope: "environment", | ||
| period: "24h", | ||
| }); | ||
| return { body: { results: [{ bucket: "2026-01-01T00:00:00Z", runs: 1 }] } }; | ||
| }); | ||
| try { | ||
| // The rows aren't embedded in the block — the panel stays the runner. | ||
| await expect(renderView(ENV_CTX, CHART_SPEC)).resolves.toEqual({ blocks: CHART_SPEC.blocks }); | ||
| expect(queryRequests(fetchStub.requests)).toHaveLength(1); | ||
| } finally { | ||
| fetchStub.restore(); | ||
| } | ||
| }); |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Move the request-body assertion out of the fetch stub.
The expect at Line 1911 runs inside the respond callback, so a failure throws from inside globalThis.fetch. The test at Line 1926 proves render_view tolerates a thrown fetch and still commits the chart. A wrong request body would therefore make the stub throw, the tool would swallow it, and the assertion at Line 1919 would still pass. The test would report success while the validation request was never checked.
Record the body in the stub and assert it after the call.
💚 Proposed fix
it("render_view commits the chart when its query runs, validating it once", async () => {
+ const bodies: unknown[] = [];
const fetchStub = stubFetch((url, init) => {
if (url.endsWith("/jwt")) return { body: { token: "jwt_1" } };
- // The validation runs the same window the panel will render.
- expect(JSON.parse(String(init?.body))).toMatchObject({
- scope: "environment",
- period: "24h",
- });
+ bodies.push(JSON.parse(String(init?.body)));
return { body: { results: [{ bucket: "2026-01-01T00:00:00Z", runs: 1 }] } };
});
try {
// The rows aren't embedded in the block — the panel stays the runner.
await expect(renderView(ENV_CTX, CHART_SPEC)).resolves.toEqual({ blocks: CHART_SPEC.blocks });
expect(queryRequests(fetchStub.requests)).toHaveLength(1);
+ // The validation runs the same window the panel will render.
+ expect(bodies).toEqual([expect.objectContaining({ scope: "environment", period: "24h" })]);
} finally {
fetchStub.restore();
}
});📝 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.
| it("render_view commits the chart when its query runs, validating it once", async () => { | |
| const fetchStub = stubFetch((url, init) => { | |
| if (url.endsWith("/jwt")) return { body: { token: "jwt_1" } }; | |
| // The validation runs the same window the panel will render. | |
| expect(JSON.parse(String(init?.body))).toMatchObject({ | |
| scope: "environment", | |
| period: "24h", | |
| }); | |
| return { body: { results: [{ bucket: "2026-01-01T00:00:00Z", runs: 1 }] } }; | |
| }); | |
| try { | |
| // The rows aren't embedded in the block — the panel stays the runner. | |
| await expect(renderView(ENV_CTX, CHART_SPEC)).resolves.toEqual({ blocks: CHART_SPEC.blocks }); | |
| expect(queryRequests(fetchStub.requests)).toHaveLength(1); | |
| } finally { | |
| fetchStub.restore(); | |
| } | |
| }); | |
| it("render_view commits the chart when its query runs, validating it once", async () => { | |
| const bodies: unknown[] = []; | |
| const fetchStub = stubFetch((url, init) => { | |
| if (url.endsWith("/jwt")) return { body: { token: "jwt_1" } }; | |
| bodies.push(JSON.parse(String(init?.body))); | |
| return { body: { results: [{ bucket: "2026-01-01T00:00:00Z", runs: 1 }] } }; | |
| }); | |
| try { | |
| // The rows aren't embedded in the block — the panel stays the runner. | |
| await expect(renderView(ENV_CTX, CHART_SPEC)).resolves.toEqual({ blocks: CHART_SPEC.blocks }); | |
| expect(queryRequests(fetchStub.requests)).toHaveLength(1); | |
| // The validation runs the same window the panel will render. | |
| expect(bodies).toEqual([expect.objectContaining({ scope: "environment", period: "24h" })]); | |
| } finally { | |
| fetchStub.restore(); | |
| } | |
| }); |
| for (const block of blocks) { | ||
| if (block.type !== "investigation") { | ||
| rendered.push(block); | ||
| continue; | ||
| } | ||
|
|
||
| // Canonical URIs are built before anything is stored or emitted, and a citation | ||
| // that can't be canonicalized fails the call by name. | ||
| let canonicalized: ReturnType<typeof canonicalizeInvestigationState>; | ||
| try { | ||
| canonicalized = canonicalizeInvestigationState( | ||
| (block as InvestigationBlockBodyInput).investigation, | ||
| { projectRef, environmentId: ctx.environmentId }, | ||
| reads | ||
| ); | ||
| } catch (error) { | ||
| return { | ||
| error: `Couldn't cite that evidence: ${ | ||
| error instanceof Error ? error.message : "a citation was malformed" | ||
| }. Fix or remove those citations and render again.`, | ||
| }; | ||
| } | ||
| if (canonicalized.errors.length > 0) { | ||
| return { | ||
| error: `Couldn't cite some of that evidence: ${canonicalized.errors.join( | ||
| "; " | ||
| )}. Fix or remove those citations and render again.`, | ||
| }; | ||
| } | ||
| const state = canonicalized.state; | ||
|
|
||
| // A storage failure's message can carry the full SQL text, which must never reach | ||
| // the transcript. | ||
| let result: Awaited<ReturnType<InvestigationsCapability["upsert"]>>; | ||
| try { | ||
| result = await ctx.investigations.upsert({ | ||
| id: currentInvestigationId ?? continueId, | ||
| projectRef, | ||
| environmentRef: ctx.environmentId, | ||
| state, | ||
| }); | ||
| } catch (error) { | ||
| console.error("investigation upsert failed", error); | ||
| return { | ||
| error: | ||
| "Couldn't save the investigation right now. Say what you found in prose, honestly — if a card is already open it will be closed as inconclusive when the turn ends.", | ||
| }; | ||
| } | ||
|
|
||
| if (!result.ok) { | ||
| // Nothing was written, so no card can be rendered. | ||
| return { | ||
| error: | ||
| result.error === "context_mismatch" | ||
| ? "That investigation belongs to a different chat, project, or environment, so it can't be updated here." | ||
| : "That investigation no longer exists. Render again without an investigationId to start a new one.", | ||
| }; | ||
| } | ||
|
|
||
| currentInvestigationId = result.id; | ||
| investigationId = result.id; | ||
| revision = result.revision; | ||
|
|
||
| const capabilities = investigationCapabilities(state, reads); | ||
|
|
||
| const parsed = investigationBlockSchema.safeParse({ | ||
| ...block, | ||
| investigation: state, | ||
| ...(capabilities ? { capabilities } : {}), | ||
| id: result.id, | ||
| revision: result.revision, | ||
| version: VIEW_BLOCK_VERSION, | ||
| }); | ||
| if (!parsed.success) { | ||
| return { error: "Couldn't render that investigation: the card payload didn't validate." }; | ||
| } | ||
| rendered.push(parsed.data); | ||
| } |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Inspect the render_view schema for a limit on investigation blocks.
rg -n -C15 'renderViewSchema' internal-packages/dashboard-agent/src/tool-schemas.ts
# Inspect the view block union and any max-length constraint on blocks.
rg -n -C10 'investigationBlockSchema|viewBlockSchema|blocks' internal-packages/dashboard-agent-contracts/src/blocks.tsRepository: triggerdotdev/trigger.dev
Length of output: 7288
🏁 Script executed:
#!/bin/bash
# Inspect the exact schema shape for blocks and inspect the renderer's currentInvestigationId loop behavior.
sed -n '110,225p' internal-packages/dashboard-agent/src/tool-investigations.ts | cat -n
sed -n '294,306p' internal-packages/dashboard-agent/src/tool-schemas.ts | cat -n
sed -n '584,591p' internal-packages/dashboard-agent-contracts/src/blocks.ts | cat -nRepository: triggerdotdev/trigger.dev
Length of output: 7204
Reject or separate multiple investigation blocks in one render.
renderViewSchema allows blocks as z.array(viewBlockInputSchema).min(1) without a max(1), and the renderer loops over every type === "investigation" block. After one block creates currentInvestigationId, subsequent investigation blocks reuse it and update the same record, erasing the earlier block’s state while still returning multiple cards. Return an error for more than one investigation block, or create a separate record for each.
… the mid-flight one A turn stores its messages before the model finishes, so the completed bodies arrived against ids that already existed and were skipped. Reopening a chat then replayed a tool call that never ends.
| function metricDelta(metric: LayoutMetricInput): LayoutDelta | undefined { | ||
| const delta = metric.delta; | ||
| if (delta && delta.mult !== undefined && delta.mult > 1 && delta.dir !== "flat") { | ||
| return { | ||
| text: `${delta.dir === "up" ? REPORT_GLYPH.up : REPORT_GLYPH.down} ${delta.mult}×`, | ||
| dir: delta.dir, | ||
| }; | ||
| } | ||
| return metric.normal === undefined | ||
| ? undefined | ||
| : { text: `${REPORT_GLYPH.flat} flat`, dir: "flat" }; | ||
| } |
There was a problem hiding this comment.
🟡 A metric that has collapsed well below normal is reported as unchanged
A measurement that fell below its baseline is labelled unchanged ({ text: "→ flat" } at apps/webapp/app/presenters/v3/reports/report-layout.ts:534-535) whenever the drop is large enough, so a report can say a number is steady while it has actually fallen away.
Impact: A reader of the health report sees "flat" next to a figure that has dropped by a factor of two or more.
A downward multiplier always rounds to 0 or 1, so it never clears the `> 1` gate
delta() (apps/webapp/app/presenters/v3/reports/report-view-model.ts:41-47) sets dir: "down" and mult: Math.round(value / normal), which for any value below 1.5 × normal is 0 or 1. metricDelta only emits an arrow when delta.mult > 1, so every down delta falls through to the normal !== undefined branch and renders → flat — including a metric that dropped from 100 to 5 (mult === 0).
The previous renderer handled this explicitly: deltaSegment returned the bare ↓ arrow for a down delta precisely because "a drop rounds to 0×/1×, meaningless — the arrow already says below normal". That case is now lost.
A fix is to keep the arrow-only rendering for dir === "down" rather than folding it into the flat branch.
Prompt for agents
In apps/webapp/app/presenters/v3/reports/report-layout.ts, `metricDelta` only renders a direction arrow when `delta.mult > 1`. Because `delta()` in report-view-model.ts computes `mult = Math.round(value / normal)`, a metric that is BELOW its baseline always has `mult` of 0 or 1, so every downward movement — including a collapse to 5% of normal — renders as `→ flat`. The pre-refactor renderer (`deltaSegment` in renderMarkdown.ts) deliberately rendered a bare `↓` for `dir === "down"` for exactly this reason. Restore a distinct rendering for a downward delta (arrow only, or an inverted multiplier such as `↓ 20×` computed from normal/value) so a real drop is not reported as unchanged, and update the affected snapshots.
Was this helpful? React with 👍 or 👎 to provide feedback.
| /** True when an output is a tool failure: unfolded (`isError`) or a plain `error` field. */ | ||
| export function evalOutputErrored(output: unknown): boolean { | ||
| if (output === null || typeof output !== "object" || Array.isArray(output)) return false; | ||
| return (output as { isError?: unknown }).isError === true || "error" in output; | ||
| } |
There was a problem hiding this comment.
🟡 Successful data lookups are recorded as tool failures in the quality-eval data
A perfectly successful lookup is treated as a failed one ("error" in output at internal-packages/dashboard-agent/src/eval-policy.ts:256) whenever its result merely mentions an error field with nothing in it, so the stored quality records say the assistant's tools broke when they didn't.
Impact: The judged-turn rows and the judge's own input claim a tool failure on turns where nothing failed, skewing the quality data.
`curateRun`/`curateDeploy` always emit an `error` key, set to `undefined` on success
curateRun returns error: run.error ? { name, message } : undefined (internal-packages/dashboard-agent/src/tool-curation.ts:50), and curateDeploy does the same. The key is therefore present on the returned object even for a run that completed. evalOutputErrored tests "error" in output, which is true for a present-but-undefined key, so:
extractToolActivity→redactEvalToolValue→annotateEvalErrorCategorystampserrorCategory: "unknown"onto the redacted result the judge sees, andJUDGE_SYSTEMtells the judge that anerrorCategorymarks a failed tool call.evalTurncomputestoolError = payload.toolActivity.some((t) => toolResultErrored(t.output))(internal-packages/dashboard-agent/src/eval-turn.ts:179), sotool_erroris writtentrueon thechat_turn_evalsrow for any turn that calledget_runon a healthy run.
(The toolError mis-classification pre-dates this PR; the new errorCategory annotation now propagates it into the judge prompt as well.) Checking for a non-undefined value — (output as any).error != null — rather than key presence fixes both.
| /** True when an output is a tool failure: unfolded (`isError`) or a plain `error` field. */ | |
| export function evalOutputErrored(output: unknown): boolean { | |
| if (output === null || typeof output !== "object" || Array.isArray(output)) return false; | |
| return (output as { isError?: unknown }).isError === true || "error" in output; | |
| } | |
| /** True when an output is a tool failure: unfolded (`isError`) or a populated `error` field. */ | |
| export function evalOutputErrored(output: unknown): boolean { | |
| if (output === null || typeof output !== "object" || Array.isArray(output)) return false; | |
| const record = output as { isError?: unknown; error?: unknown }; | |
| // A curated result carries `error: undefined` on success, so key presence is not a failure. | |
| return record.isError === true || ("error" in record && record.error != null); | |
| } |
Was this helpful? React with 👍 or 👎 to provide feedback.
| import { | ||
| ArrowPathIcon, | ||
| ArrowUpIcon, |
There was a problem hiding this comment.
🔍 The @deprecated note is not true at this commit: AskAI is still mounted
The header says "Nothing mounts this any more — every Ask AI entry point now opens Ask Trigger." AskAIRoot is still rendered by apps/webapp/app/components/navigation/HelpAndFeedbackPopover.tsx:62 and <AskAI /> by apps/webapp/app/components/BlankStatePanels.tsx:295 and :683. env.server.ts likewise now claims KAPA_AI_WEBSITE_ID is unread "while no surface mounts the widget", but useKapaWebsiteId() is still consumed by the mounted component. The notes are accurate only after the follow-up UI PR; as written they will mislead whoever does the promised removal of @kapaai/react-sdk and the env var.
(Refers to lines 7-11)
Was this helpful? React with 👍 or 👎 to provide feedback.
|
|
||
| let received = 0; | ||
| const onData = (chunk: Buffer | string) => { | ||
| received += Buffer.byteLength(chunk); | ||
| if (received <= limit) return; | ||
| req.off("data", onData); | ||
| req.pause(); | ||
| refuse(res); | ||
| // Torn down only once the refusal is on the wire, or the client never reads it. | ||
| res.once("finish", () => req.destroy()); | ||
| }; | ||
|
|
||
| req.on("data", onData); | ||
| req.pause(); | ||
| req.once("end", () => req.off("data", onData)); |
There was a problem hiding this comment.
🔍 The ingress cap relies on data-listener + pause() co-existing with the route's own reader
capRequestBody attaches a data listener (which switches the stream to flowing mode) and immediately calls req.pause(), on the assumption that a later read() by Remix's body reader will still emit data for each chunk so the counter keeps working, and that nothing is lost. That is true for Node's paused-mode read(), and the express-based test covers the happy and refusal paths — but it is a mode-mixing pattern that is sensitive to how Remix constructs the request stream (Readable.toWeb vs manual iteration) and to any body parser mounted earlier in the chain. Worth re-checking if the Remix/Node version moves, since a silent failure here means the cap stops counting rather than erroring.
Was this helpful? React with 👍 or 👎 to provide feedback.
…New chat The gate counted transcript length, and a warm first turn arrives with the model's opening step already in it — so the very first exchange looked like a later one.
| const range = capRead(lines.slice(from - 1, to).join("\n")); | ||
| return { | ||
| path, | ||
| content: range.content, | ||
| startLine: from, | ||
| endLine: to, | ||
| ...(range.truncated ? { truncated: true, notice: READ_TRUNCATION_NOTICE } : {}), | ||
| }; |
There was a problem hiding this comment.
🟡 A partly-shown source file is reported as if the whole requested range were returned
A requested line range that gets shortened to fit the size cap is still labelled with the originally requested end line (endLine: to at internal-packages/dashboard-agent/src/repo-tools.ts:275), so the caller is told it received lines it never got.
Impact: The agent can cite a line number that isn't in the text it actually read, so a code citation on an investigation card can point at the wrong place.
Why the reported range and the returned content disagree
capRead is applied after the slice, so range.content may contain far fewer lines than lines.slice(from - 1, to). The response still returns startLine: from, endLine: to verbatim. A caller asking for lines 1–4000 of a large file gets ~1500 lines back but is told the payload spans 1–4000. The unranged branch below it (repo-tools.ts:280-285) has no such claim, so only the range path is affected. The fix is to derive the reported endLine from the number of lines actually in range.content.
| const range = capRead(lines.slice(from - 1, to).join("\n")); | |
| return { | |
| path, | |
| content: range.content, | |
| startLine: from, | |
| endLine: to, | |
| ...(range.truncated ? { truncated: true, notice: READ_TRUNCATION_NOTICE } : {}), | |
| }; | |
| const range = capRead(lines.slice(from - 1, to).join("\n")); | |
| return { | |
| path, | |
| content: range.content, | |
| startLine: from, | |
| endLine: range.truncated ? from + range.content.split("\n").length - 1 : to, | |
| ...(range.truncated ? { truncated: true, notice: READ_TRUNCATION_NOTICE } : {}), | |
| }; |
Was this helpful? React with 👍 or 👎 to provide feedback.
| // Membership-scoped: dev rows are per-developer, so a token must never be minted for | ||
| // someone else's environment — or, when nothing resolves, for no environment at all. | ||
| const runtimeEnv = await findEnvironmentBySlug(project.id, envParam, userId); | ||
| if (!runtimeEnv) return json({ error: "Environment not found" }, { status: 404 }); | ||
| const environmentName = ENV_NAME_BY_TYPE[runtimeEnv.type]; |
There was a problem hiding this comment.
🟡 A failed chat start still leaves an empty conversation in the user's history
The conversation row is written (createChat at apps/webapp/app/routes/resources.orgs.$organizationSlug.projects.$projectParam.env.$envParam.dashboard-agent.ts:225-230) before the environment it belongs to is looked up, so when that lookup fails the empty conversation stays behind.
Impact: Users can accumulate blank "New chat" entries in their history that were never actually started.
Ordering in the `create` intent
Inside the try block the sequence is createChat(...) → findEnvironmentBySlug(...) → if (!runtimeEnv) return json({ error: "Environment not found" }, { status: 404 }). There is no compensating delete, and listChats selects every non-deleted chat, so the orphan is visible. Resolving the environment before creating the chat (or soft-deleting on the failure path) removes the window.
Was this helpful? React with 👍 or 👎 to provide feedback.
| }, | ||
| // No plugin → permissive, matching the fallback's PAT behaviour. | ||
| ability: permissiveAbility, | ||
| // A delegated token is a downgrade of the user: never the blanket ability a PAT gets here. | ||
| ability: buildJwtAbility(claims.cap ?? CAPLESS_USER_ACTOR_SCOPES), |
There was a problem hiding this comment.
🔍 Capless user-actor tokens lose their blanket ability on self-hosted — check every existing UAT mint site
The self-hosted RBAC fallback previously returned permissiveAbility for any verified user-actor token; it now builds the ability from claims.cap, defaulting a capless token to ["read:all"]. That is the right hardening for the dashboard agent (which always sets a cap), but every other UAT flow that mints without a cap silently becomes read-only on OSS. signUserActorToken is exported from @trigger.dev/plugins, and the comment in userActorEnvironment.server.ts notes "MCP and the CLI may use their existing ones." If any of those tokens are used for a write (triggering a task, minting a write-scoped env JWT), that call now 403s on self-hosted where it previously succeeded. Worth confirming no capless UAT is on a write path before merging.
Was this helpful? React with 👍 or 👎 to provide feedback.
…finalise only this turn's messages Review of #4418: the cloud path builds the ability from the user's role, so a read-only delegated token could exchange it for a write JWT; and the finalisable set was the whole replayed transcript rather than what the turn produced.
| // Metrics are informational unless this is true. Stale, absent and unmeasurable all read false. | ||
| trustworthy: !telemetryStale && telemetry !== "none" && !flowUnmeasured, | ||
| telemetry, | ||
| untrustworthyReason: telemetryStale | ||
| ? "telemetry_stale" | ||
| : telemetry === "none" | ||
| ? "telemetry_absent" | ||
| : flowUnmeasured | ||
| ? "flow_unmeasured" | ||
| : undefined, |
There was a problem hiding this comment.
🟡 Healthy environments are labelled "stale data" in the health report
A report is marked untrustworthy (trustworthy: !telemetryStale && telemetry !== "none" && !flowUnmeasured at apps/webapp/app/presenters/v3/reports/health/health.ts:203) whenever there is simply no telemetry signal or the queue depth couldn't be measured, and every surface then shows the "stale data" flag and a note claiming the telemetry is stale.
Impact: Environments whose data is merely absent or unmeasurable — including every environment still on the fallback data path — are told their report is based on stale telemetry, which is not what happened.
How "absent" and "unmeasurable" get relabelled as "stale"
reportIsTrustworthy in apps/webapp/app/presenters/v3/reports/report-layout.ts:93 treats facts.trustworthy === false as one thing only — its own doc comment says "means the telemetry behind the verdict is stale" — and buildReportLayout therefore emits trust: { badge: REPORT_LABELS.staleBadge, note: REPORT_LABELS.staleNote } (report-layout.ts:351-353). The labels are "stale data" and "The telemetry behind this report is stale, so the numbers below are informational only." (report-layout.ts:55-57).
But assessHealth now sets trustworthy false for three distinct states, and only one of them is staleness:
telemetryStale— genuinely stale.telemetry === "none"—liveness.telemetryAgeMs === null, i.e. no signal at all. The surrounding comment even says such an env "stays neutral for the reader".flowUnmeasured— the queue depth was a placeholder.
The untrustworthyReason discriminator written alongside it (health.ts:205-211) is never read by the layout, so all three collapse into the stale wording.
This is not a rare path. SnapshotFlowSource now returns telemetryLastTs: null unconditionally (apps/webapp/app/presenters/v3/reports/health/health-data.ts:523, previously freshestTs(ctx.liveScalar.last_activity)), so every report served from the snapshot fallback — any environment where env_metrics isn't populated yet — resolves to telemetry: "none" and renders with the stale-data flag, even when the verdict itself is green.
The existing coverage doesn't catch it: apps/webapp/test/reportHealth.test.ts asserts the no-signal case renders ⚪ and not 🟡, but never asserts the absence of the 🚩 stale data badge.
Prompt for agents
`assessHealth` in apps/webapp/app/presenters/v3/reports/health/health.ts sets `facts.trustworthy` to false for three different states — telemetry stale, telemetry absent (`telemetry === "none"`), and flow unmeasured — and records which one in `facts.untrustworthyReason`. However `reportIsTrustworthy` / `buildReportLayout` in apps/webapp/app/presenters/v3/reports/report-layout.ts only look at `trustworthy` and unconditionally render `REPORT_LABELS.staleBadge` ("stale data") and `REPORT_LABELS.staleNote` ("The telemetry behind this report is stale…"), so an environment with no telemetry signal or an unmeasurable queue depth is told its data is stale.
This is the common case rather than an edge case: SnapshotFlowSource now always returns `telemetryLastTs: null` (health-data.ts), so every report served from the snapshot fallback resolves to `telemetry: "none"` and carries the stale flag even when the verdict is green.
Possible approaches: have the layout read `facts.untrustworthyReason` and choose badge/note wording per reason (stale vs. no telemetry vs. depth unmeasurable), or narrow `reportIsTrustworthy` so only genuine staleness produces the trust block and give the other two states their own, accurate caveat. Add a test asserting a no-signal healthy env does not render the stale badge.
Was this helpful? React with 👍 or 👎 to provide feedback.
| export function prepareTurnMessages(args: { | ||
| messages: ModelMessage[]; | ||
| reason: string; | ||
| }): ModelMessage[] { | ||
| if (args.messages.length === 0) return args.messages; | ||
| return withCacheBreakpointOnLast( | ||
| sanitizeReplayedToolInputs( | ||
| args.reason === "run" ? args.messages : withDurableState(args.messages, chat.history.all()) | ||
| ) | ||
| ); |
There was a problem hiding this comment.
🔍 Durable-state note is injected on every non-"run" prepareMessages reason
prepareTurnMessages applies withDurableState for any reason other than "run", and withDurableState splices a synthetic user message in at index 1 (internal-packages/dashboard-agent/src/compaction.ts:260-264). That is safe for the two compaction rebuild reasons the comment names, where messages[0] is the summary. If the SDK ever emits another reason (a per-step or tool-approval rebuild, say) whose messages[0] is an ordinary turn message, a user message would be inserted between an assistant tool-call and its tool result, which Anthropic rejects. Worth confirming the exhaustive set of prepareMessages reasons the SDK can pass and narrowing the condition to an explicit allow-list rather than !== "run".
Was this helpful? React with 👍 or 👎 to provide feedback.
| // Measured against expected buckets when the cadence is known, not against received rows. | ||
| const throttledBuckets = series.filter((r) => num(r.throttled) > 0).length; | ||
| const throttledDenominator = sampling?.expectedBuckets ?? series.length; | ||
| const throttledShare = throttledDenominator > 0 ? throttledBuckets / throttledDenominator : 0; |
There was a problem hiding this comment.
🔍 Throttled share is measured against expected buckets while the numerator counts received ones
throttledShare now divides the count of received buckets that reported throttling by sampling.expectedBuckets rather than by series.length. On a gappy window this systematically understates throttling — a queue throttled in every bucket that actually arrived reads as e.g. 0.5 when half the buckets are missing, which can drop it below t.throttledShare (0.25) or t.pinnedShare and cause queue_limit_throttling not to be selected. The concurrency-shaped causes are separately guarded by coverage.sufficient, but the throttled discriminator is not, so a heavily-gapped window silently biases the cause tree away from queue throttling and toward the fallback symptom reasons. Worth confirming that's the intended trade rather than the pinned-share change being applied one level too broadly.
Was this helpful? React with 👍 or 👎 to provide feedback.
…s its metrics The dashboard agent asks for a queue's live row — paused, depth, limit — through the environment JWT it exchanges for. The metrics route has accepted that JWT all along; the retrieve route answered 401, so the agent saw no queue at all.
There was a problem hiding this comment.
🧹 Nitpick comments (1)
apps/webapp/test/queueRetrieveJwt.test.ts (1)
13-25: 🔒 Security & Privacy | 🔵 Trivial | 🏗️ Heavy liftAdd a behavior-level authentication test.
These assertions only search for literal source text. They can pass even if
createLoaderApiRouteignoresallowJWTor thequeuesauthorization check fails at runtime. The authentication path inapps/webapp/app/services/apiAuth.server.ts, Lines [137-203], is not exercised. Use the existing route/authentication harness to send an environment JWT and assert the queue response and authorization scope.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 881a64c9-f1c8-4bd0-891e-6fb528d45648
📒 Files selected for processing (2)
apps/webapp/app/routes/api.v1.queues.$queueParam.tsapps/webapp/test/queueRetrieveJwt.test.ts
📜 Review details
🧰 Additional context used
📓 Path-based instructions (12)
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
**/*.{ts,tsx}: Use types over interfaces for TypeScript
Avoid using enums; prefer string unions or const objects instead
**/*.{ts,tsx}: Prefer static imports over dynamicimport(); use dynamic imports only for unresolvable circular dependencies, genuine performance code splitting, or conditional runtime loading.
Import Trigger.dev tasks from@trigger.dev/sdk; never use@trigger.dev/sdk/v3or deprecatedclient.defineJob.
Add agentcrumbs while writing code using approved namespaces; mark lines with//@Crumbsor blocks with `// `#region` `@crumbs, and strip them before merging.
Files:
apps/webapp/test/queueRetrieveJwt.test.tsapps/webapp/app/routes/api.v1.queues.$queueParam.ts
{packages/core,apps/webapp}/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use zod for validation in packages/core and apps/webapp
Files:
apps/webapp/test/queueRetrieveJwt.test.tsapps/webapp/app/routes/api.v1.queues.$queueParam.ts
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use function declarations instead of default exports
Files:
apps/webapp/test/queueRetrieveJwt.test.tsapps/webapp/app/routes/api.v1.queues.$queueParam.ts
**/*.{test,spec}.{ts,tsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use vitest for all tests in the Trigger.dev repository
**/*.{test,spec}.{ts,tsx}: Use Vitest exclusively and never mock dependencies; use Testcontainers for integration dependencies.
Place test files next to the source files they test.
Files:
apps/webapp/test/queueRetrieveJwt.test.ts
**/*.ts
📄 CodeRabbit inference engine (.cursor/rules/otel-metrics.mdc)
**/*.ts: When creating or editing OTEL metrics (counters, histograms, gauges), ensure metric attributes have low cardinality by using only enums, booleans, bounded error codes, or bounded shard IDs
Do not use high-cardinality attributes in OTEL metrics such as UUIDs/IDs (envId, userId, runId, projectId, organizationId), unbounded integers (itemCount, batchSize, retryCount), timestamps (createdAt, startTime), or free-form strings (errorMessage, taskName, queueName)
When exporting OTEL metrics via OTLP to Prometheus, be aware that the exporter automatically adds unit suffixes to metric names (e.g., 'my_duration_ms' becomes 'my_duration_ms_milliseconds', 'my_counter' becomes 'my_counter_total'). Account for these transformations when writing Grafana dashboards or Prometheus queries
Files:
apps/webapp/test/queueRetrieveJwt.test.tsapps/webapp/app/routes/api.v1.queues.$queueParam.ts
apps/webapp/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/webapp.mdc)
apps/webapp/**/*.{ts,tsx}: Access environment variables through theenvexport ofenv.server.tsinstead of directly accessingprocess.env
Use subpath exports from@trigger.dev/corepackage instead of importing from the root@trigger.dev/corepathDo not reintroduce the removed v1 execution path;
RunEngineVersion.V1branches may only reject or finalize gracefully so v3 clients receive a clean 4xx, never a 5xx.
Files:
apps/webapp/test/queueRetrieveJwt.test.tsapps/webapp/app/routes/api.v1.queues.$queueParam.ts
apps/webapp/**/*.test.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/webapp.mdc)
Do not import
env.server.tsdirectly or indirectly into test files; instead pass environment-dependent values through options/parameters to make code testable
Files:
apps/webapp/test/queueRetrieveJwt.test.ts
apps/**/*.{ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
For apps, use
typecheckfor verification and never usebuildas the correctness check.
Files:
apps/webapp/test/queueRetrieveJwt.test.tsapps/webapp/app/routes/api.v1.queues.$queueParam.ts
apps/webapp/**/*.{test,spec}.{ts,tsx}
📄 CodeRabbit inference engine (apps/webapp/CLAUDE.md)
Test files must not import
app/env.server.ts; pass configuration as options instead.
Files:
apps/webapp/test/queueRetrieveJwt.test.ts
apps/webapp/app/**/*.{ts,tsx}
📄 CodeRabbit inference engine (apps/webapp/CLAUDE.md)
apps/webapp/app/**/*.{ts,tsx}: For dashboard changes, visually verify the running Remix app with Chrome DevTools MCP, using snapshots, screenshots, interaction, and console-message checks as appropriate.
UseuseCallbackanduseMemoonly for context provider values, expensive derived data used as a dependency, or stable references required by dependency arrays; do not wrap ordinary event handlers or trivial computations.
Use named constants for sentinel or placeholder values instead of scattering raw string literals across comparisons.
Files:
apps/webapp/app/routes/api.v1.queues.$queueParam.ts
apps/webapp/app/routes/**/*.ts
📄 CodeRabbit inference engine (apps/webapp/CLAUDE.md)
apps/webapp/app/routes/**/*.ts: Use Remix flat-file route conventions with dot-separated segments; for example,api.v1.tasks.$taskId.trigger.tsmaps to/api/v1/tasks/:taskId/trigger.
PAT-authenticated API routes must resolve their target organization or project within the caller's membership scope, using a membership filter or a helper such asfindProjectByReforresolveOrganizationForApiUser; RBAC authorization alone is insufficient.
Files:
apps/webapp/app/routes/api.v1.queues.$queueParam.ts
apps/webapp/app/**/*.ts
📄 CodeRabbit inference engine (apps/webapp/CLAUDE.md)
apps/webapp/app/**/*.ts: Never userequest.signalto detect client disconnects. UsegetRequestAbortSignal()fromapp/services/httpAsyncStorage.server.ts, which is wired to Express response close events.
Access environment variables through theenvexport fromapp/env.server.ts; never useprocess.envdirectly.
Always use PrismafindFirstinstead offindUnique.
Always use the$transactionhelper from~/db.server, never callprisma.$transactionor$replica.$transactiondirectly. Pass isolation levels as strings, useSerializablefor correctness-critical read-then-write invariants, and guard possibly undefined helper results when a definite value is required.
Files:
apps/webapp/app/routes/api.v1.queues.$queueParam.ts
🧠 Learnings (17)
📚 Learning: 2026-03-22T13:26:12.060Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 3244
File: apps/webapp/app/components/code/TextEditor.tsx:81-86
Timestamp: 2026-03-22T13:26:12.060Z
Learning: In the triggerdotdev/trigger.dev codebase, do not flag `navigator.clipboard.writeText(...)` calls for `missing-await`/`unhandled-promise` issues. These clipboard writes are intentionally invoked without `await` and without `catch` handlers across the project; keep that behavior consistent when reviewing TypeScript/TSX files (e.g., usages like in `apps/webapp/app/components/code/TextEditor.tsx`).
Applied to files:
apps/webapp/test/queueRetrieveJwt.test.tsapps/webapp/app/routes/api.v1.queues.$queueParam.ts
📚 Learning: 2026-03-22T19:24:14.403Z
Learnt from: matt-aitken
Repo: triggerdotdev/trigger.dev PR: 3187
File: apps/webapp/app/v3/services/alerts/deliverErrorGroupAlert.server.ts:200-204
Timestamp: 2026-03-22T19:24:14.403Z
Learning: In the triggerdotdev/trigger.dev codebase, webhook URLs are not expected to contain embedded credentials/secrets (e.g., fields like `ProjectAlertWebhookProperties` should only hold credential-free webhook endpoints). During code review, if you see logging or inclusion of raw webhook URLs in error messages, do not automatically treat it as a credential-leak/secrets-in-logs issue by default—first verify the URL does not contain embedded credentials (for example, no username/password in the URL, no obvious secret/token query params or fragments). If the URL is credential-free per this project’s conventions, allow the logging.
Applied to files:
apps/webapp/test/queueRetrieveJwt.test.tsapps/webapp/app/routes/api.v1.queues.$queueParam.ts
📚 Learning: 2026-05-18T08:21:27.694Z
Learnt from: d-cs
Repo: triggerdotdev/trigger.dev PR: 3632
File: apps/webapp/sentry.server.ts:4-21
Timestamp: 2026-05-18T08:21:27.694Z
Learning: When handling Prisma error P1001 ("Can't reach database server") in TypeScript, don’t assume a single error shape. Prisma can surface P1001 via two different error classes/fields: `PrismaClientKnownRequestError` exposes it as `err.code === "P1001"` (common during mid-query connection drops), while `PrismaClientInitializationError` exposes it as `err.errorCode === "P1001"` (common on client startup failure). Therefore, predicates should use `err.code === "P1001" || err.errorCode === "P1001"`. Do not flag `err.code === "P1001"` as “unreachable/never matches,” as it is expected in production.
Applied to files:
apps/webapp/test/queueRetrieveJwt.test.tsapps/webapp/app/routes/api.v1.queues.$queueParam.ts
📚 Learning: 2026-05-18T08:21:27.694Z
Learnt from: d-cs
Repo: triggerdotdev/trigger.dev PR: 3632
File: apps/webapp/sentry.server.ts:4-21
Timestamp: 2026-05-18T08:21:27.694Z
Learning: When handling Prisma errors for P1001 ("Can't reach database server"), do not assume it only appears under a single property name. Prisma may surface P1001 via either `PrismaClientKnownRequestError` (`err.code === "P1001"`, e.g., mid-query connection drops) or `PrismaClientInitializationError` (`err.errorCode === "P1001"`, e.g., client startup connection failure). To reliably detect the condition, check `err.code === "P1001" || err.errorCode === "P1001"`, and avoid review rules that would incorrectly flag `err.code === "P1001"` as unreachable/never-matching.
Applied to files:
apps/webapp/test/queueRetrieveJwt.test.tsapps/webapp/app/routes/api.v1.queues.$queueParam.ts
📚 Learning: 2026-06-13T19:53:13.759Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 3937
File: packages/trigger-sdk/skills/realtime-and-frontend/SKILL.md:258-260
Timestamp: 2026-06-13T19:53:13.759Z
Learning: When reviewing code that uses `trigger.dev/react-hooks`’s `useRealtimeRun`, preserve the call signature where the first argument is the full realtime handle object (not `handle.id`). This is intentional to maintain type-safety and is consistent with the official docs; do not suggest changing the first argument from the handle object to `handle.id`.
Applied to files:
apps/webapp/test/queueRetrieveJwt.test.tsapps/webapp/app/routes/api.v1.queues.$queueParam.ts
📚 Learning: 2026-06-17T17:13:49.929Z
Learnt from: matt-aitken
Repo: triggerdotdev/trigger.dev PR: 3948
File: apps/webapp/app/routes/_app.orgs.$organizationSlug.projects.$projectParam.env.$envParam.bulk-actions.$bulkActionParam/route.tsx:48-62
Timestamp: 2026-06-17T17:13:49.929Z
Learning: In triggerdotdev/trigger.dev, within `dashboardLoader`/`dashboardAction` (or similar context resolver code) whenever you resolve an organization ID from an organization slug for RBAC/enterprise authorization scope, always read from the primary Prisma client (`prisma`), not `$replica`. Using `$replica` can hit replica-lag and cause the RBAC lookup/authorization to run without the correct org scope (bypassing intended role enforcement). Implement the slug→org lookup with `prisma.organization.findFirst(...)` (or equivalent primary-client query) and add an inline comment documenting why the primary client is required (replica lag could lead to unscoped RBAC checks).
Applied to files:
apps/webapp/test/queueRetrieveJwt.test.tsapps/webapp/app/routes/api.v1.queues.$queueParam.ts
📚 Learning: 2026-06-23T13:04:21.413Z
Learnt from: carderne
Repo: triggerdotdev/trigger.dev PR: 4023
File: apps/webapp/app/services/upsertBranch.server.ts:14-18
Timestamp: 2026-06-23T13:04:21.413Z
Learning: In TypeScript, it’s valid to `import { type X }` and then use `typeof X` in a type-only position, e.g. `type Alias = z.infer<typeof X>`. The `type` modifier suppresses the runtime import, but the type checker still has the full exported type so `z.infer<typeof X>` can resolve correctly. In code reviews, don’t flag this as a TypeScript compile error as long as `typeof X` is used in a type context (e.g., with `z.infer`, `type` aliases, generics), not as a runtime value.
Applied to files:
apps/webapp/test/queueRetrieveJwt.test.tsapps/webapp/app/routes/api.v1.queues.$queueParam.ts
📚 Learning: 2026-05-07T12:25:18.271Z
Learnt from: d-cs
Repo: triggerdotdev/trigger.dev PR: 3531
File: apps/webapp/test/sentryTraceContext.server.test.ts:9-47
Timestamp: 2026-05-07T12:25:18.271Z
Learning: In the triggerdotdev/trigger.dev webapp test suite, it is acceptable to leave `createInMemoryTracing()` calls that register a global `NodeTracerProvider` without `afterEach`/`afterAll` teardown. Do not flag this as a test-ordering risk when the code follows the established pattern used across webapp tests (e.g., replication service/benchmark/backfiller tests). This is considered safe because `trace.getActiveSpan()` when called outside a `context.with(...)` block reads `AsyncLocalStorage.getStore()` (undefined when no `run()` scope exists), so it falls back to `ROOT_CONTEXT` with no attached span—regardless of which provider is registered.
Applied to files:
apps/webapp/test/queueRetrieveJwt.test.ts
📚 Learning: 2026-05-28T20:02:10.647Z
Learnt from: myftija
Repo: triggerdotdev/trigger.dev PR: 3772
File: apps/webapp/test/findOrCreateBackgroundWorker.test.ts:1-1
Timestamp: 2026-05-28T20:02:10.647Z
Learning: In the triggerdotdev/trigger.dev monorepo, for the `apps/webapp` package use the established convention of storing Vitest tests (unit, integration, and e2e) under `apps/webapp/test/` rather than colocating them next to source files. Do not flag files located in `apps/webapp/test/` as violating any rule that says to colocate tests with source.
Applied to files:
apps/webapp/test/queueRetrieveJwt.test.ts
📚 Learning: 2026-07-30T18:43:56.874Z
Learnt from: 0ski
Repo: triggerdotdev/trigger.dev PR: 4426
File: apps/webapp/test/memberDevEnvironments.server.test.ts:124-125
Timestamp: 2026-07-30T18:43:56.874Z
Learning: In the `apps/webapp` test suite (`apps/webapp/test/**`), respect the established test harness in `apps/webapp/test/setup.ts`: it loads `.env` and provides default values for required environment variables so that transitive imports (e.g., `~/env.server`) work without production-style wiring.
During code review, do not require dependency injection/refactoring solely to avoid this existing import path. Only introduce configuration injection if it delivers production-level value (for example, a more general `createEnvironment` abstraction that improves runtime behavior beyond test setup).
Applied to files:
apps/webapp/test/queueRetrieveJwt.test.ts
📚 Learning: 2026-05-12T21:04:05.815Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 3542
File: apps/webapp/app/components/sessions/v1/SessionStatus.tsx:1-3
Timestamp: 2026-05-12T21:04:05.815Z
Learning: In this Remix + TypeScript codebase, do not flag a server/client boundary violation when a file imports only types from a module matching `*.server`.
Specifically, it’s safe to import types using `import type { Foo } from "*.server"` or `import { type Foo } from "*.server"` because TypeScript erases type-only imports at compile time and they emit no JavaScript, so they won’t cross the Remix server/client bundle boundary.
Only raise the boundary concern for value imports (e.g., `import { Foo }` without `type`, or `import Foo`), since those produce JavaScript output.
Applied to files:
apps/webapp/test/queueRetrieveJwt.test.tsapps/webapp/app/routes/api.v1.queues.$queueParam.ts
📚 Learning: 2026-06-25T18:21:51.905Z
Learnt from: carderne
Repo: triggerdotdev/trigger.dev PR: 4039
File: apps/webapp/app/routes/invite-revoke.tsx:0-0
Timestamp: 2026-06-25T18:21:51.905Z
Learning: During the Zod v4 migration in the triggerdotdev/trigger.dev webapp, ensure any imports from `conform-to/zod` use the Zod-4 subpath: `conform-to/zod/v4` (e.g., `import { parseWithZod } from "conform-to/zod/v4"`). Do not import from the package root `conform-to/zod`, because it is the Zod 3 implementation and may load Zod-3-only symbols (e.g., `ZodBranded`, `ZodEffects`), which can throw at module load (notably with `zod4.4.3`). This should be enforced across `apps/webapp/**/*` where helpers like `parseWithZod` and `conformZodMessage` are used.
Applied to files:
apps/webapp/test/queueRetrieveJwt.test.tsapps/webapp/app/routes/api.v1.queues.$queueParam.ts
📚 Learning: 2026-07-03T17:10:21.498Z
Learnt from: 0ski
Repo: triggerdotdev/trigger.dev PR: 4148
File: apps/webapp/app/models/orgMember.server.ts:149-168
Timestamp: 2026-07-03T17:10:21.498Z
Learning: In triggerdotdev/trigger.dev, `User.email` (Prisma schema: `internal-packages/database/prisma/schema.prisma`) currently does NOT use `citext` and does NOT have a `lower(email)` functional unique index. Therefore, do not introduce Prisma queries like `where: { email: { equals: <value>, mode: "insensitive" } }` (or any case-insensitive lookup) against `User.email`, because it can force sequential scans of the `users` table under load. During review, ensure email is normalized (e.g., lowercased/trimmed) before both writes and subsequent lookups, and if true case-insensitive behavior/uniqueness is required, implement it via a separate app-wide migration (e.g., switch to `citext` and/or add a functional unique index with backfill) rather than bolting it onto individual feature PRs.
Applied to files:
apps/webapp/test/queueRetrieveJwt.test.tsapps/webapp/app/routes/api.v1.queues.$queueParam.ts
📚 Learning: 2026-05-18T14:40:02.173Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 3658
File: packages/core/src/v3/realtimeStreams/manager.test.ts:1-147
Timestamp: 2026-05-18T14:40:02.173Z
Learning: In the triggerdotdev/trigger.dev repo, the policy “Never mock anything — use testcontainers instead” should only be enforced for integration tests that interact with real external services (e.g., Redis, Postgres) via actual infrastructure. For unit tests that exercise pure in-memory logic (e.g., cache semantics) it is OK to stub collaborators such as `ApiClient` using Vitest (`vi.fn()`) to assert call counts or control behavior. Do not flag `vi.fn()`-based `ApiClient` stubs in unit tests as violations of the testcontainers policy.
Applied to files:
apps/webapp/test/queueRetrieveJwt.test.ts
📚 Learning: 2026-06-04T18:16:35.386Z
Learnt from: nicktrn
Repo: triggerdotdev/trigger.dev PR: 3836
File: apps/supervisor/src/backpressure/backpressureMonitor.ts:3-5
Timestamp: 2026-06-04T18:16:35.386Z
Learning: When reviewing TypeScript in this repo, apply the rule “prefer type aliases over interfaces” only to data/object shapes and union/intersection type modeling. If an interface is being used as a behavioral contract for collaborators to implement (e.g., method-shape interfaces that define required behavior, such as `BackpressureLogger` / `BackpressureSignalSource` in `apps/supervisor/src/backpressure/backpressureMonitor.ts`), keep it as an `interface` and do not flag it as a type-alias-vs-interface violation.
Applied to files:
apps/webapp/test/queueRetrieveJwt.test.tsapps/webapp/app/routes/api.v1.queues.$queueParam.ts
📚 Learning: 2026-06-09T17:58:04.699Z
Learnt from: 0ski
Repo: triggerdotdev/trigger.dev PR: 3879
File: apps/webapp/app/models/vercelIntegration.server.ts:619-630
Timestamp: 2026-06-09T17:58:04.699Z
Learning: In this codebase, outbound raw `fetch` calls should typically rely on Node/undici’s default request timeout (about ~300s) rather than adding a per-call `AbortController` + `setTimeout` wrapper inside individual functions (e.g. in files like `apps/webapp/app/models/vercelIntegration.server.ts`). During code review, do not flag the absence of a per-call timeout on a single `fetch` as an issue; if per-call timeouts are needed, they should be implemented via a codebase-wide convention (e.g., a shared fetch wrapper or documented pattern) rather than ad-hoc per-function changes.
Applied to files:
apps/webapp/test/queueRetrieveJwt.test.tsapps/webapp/app/routes/api.v1.queues.$queueParam.ts
📚 Learning: 2026-06-16T09:19:47.637Z
Learnt from: d-cs
Repo: triggerdotdev/trigger.dev PR: 3960
File: apps/webapp/test/prismaInfrastructureErrorCapture.test.ts:0-0
Timestamp: 2026-06-16T09:19:47.637Z
Learning: In this repo’s Vitest setup, `vitest.config.ts` uses `globals: true`, so identifiers like `vi`, `describe`, `it`, and `expect` are available as globals in Vitest test files. During code review, do not flag missing `vi`/`describe`/`it`/`expect` imports as a runtime error or correctness issue when they’re used in `*.test.ts/tsx` or `*.spec.ts/tsx` files. Explicit imports are still preferred for consistency, but they’re not required for runtime behavior.
Applied to files:
apps/webapp/test/queueRetrieveJwt.test.ts
🔇 Additional comments (2)
apps/webapp/app/routes/api.v1.queues.$queueParam.ts (1)
17-19: LGTM!apps/webapp/test/queueRetrieveJwt.test.ts (1)
10-14: 🩺 Stability & AvailabilityCheck whether the relative file paths need cwd adjustment.
readFileSyncresolves these paths fromprocess.cwd(), and webapp tests can be run withpnpm test:webappfrom the repository root. If Vitest later runs from insideapps/webapp, these reads will fail unless the paths are resolved from the test file or an absolute repo root.
| export const BASE_IMG_SRC_SOURCES = [ | ||
| "'self'", | ||
| "data:", | ||
| "blob:", | ||
| "https://avatars.githubusercontent.com", | ||
| ] as const; |
There was a problem hiding this comment.
🟡 Profile photos disappear for people who signed in with Google
The dashboard now tells the browser it may only load images from its own site, inline data and the GitHub avatar host (buildImgSrcDirective at apps/webapp/app/utils/cspImageOrigins.ts:96-98), so the Google-hosted profile photos stored for people who signed in with Google are blocked and show as broken.
Impact: Anyone who signed in with Google sees their avatar (and their teammates' avatars) vanish across the dashboard on a fresh deploy, unless a self-hoster happens to add the host by hand.
How the Google avatar host gets excluded from the new document policy
apps/webapp/app/services/googleAuth.server.ts is a supported auth provider, and apps/webapp/app/models/user.server.ts:108-110 stores authenticationProfile.photos[0].value as avatarUrl. For Google that value is on lh3.googleusercontent.com.
Before this PR no Content-Security-Policy: img-src was emitted at all, so those URLs loaded. apps/webapp/app/entry.server.tsx:94-97 now sets the directive on every document response, and BASE_IMG_SRC_SOURCES only contains 'self', data:, blob: and https://avatars.githubusercontent.com. apps/webapp/test/dashboardAgentImageCsp.test.ts even asserts expect(directive).not.toContain("googleusercontent.com"), so the omission is locked in by a test rather than an oversight that CI would catch.
Cloud deployments would need CSP_IMG_SRC_ALLOWLIST set to restore them; self-hosters using Google SSO get no warning that avatars have stopped loading.
Prompt for agents
The new document `img-src` allowlist in apps/webapp/app/utils/cspImageOrigins.ts (BASE_IMG_SRC_SOURCES) only permits 'self', data:, blob: and https://avatars.githubusercontent.com. The webapp also supports Google sign-in (apps/webapp/app/services/googleAuth.server.ts), and apps/webapp/app/models/user.server.ts persists the provider's photo URL verbatim into User.avatarUrl — for Google that is an https://lh3.googleusercontent.com URL. Since entry.server.tsx now sets this directive on every document response (previously no img-src existed), those avatars will be blocked by the browser and render broken for every Google-authenticated user and anywhere teammates' avatars are shown (members list, deployments list, bulk actions, env vars).
Decide whether the Google avatar host should join the base allowlist alongside the GitHub one, or whether avatars should be proxied through the app's own origin so no third-party host is needed. Note that apps/webapp/test/dashboardAgentImageCsp.test.ts currently asserts the directive does NOT contain googleusercontent.com, so that assertion needs revisiting too.
Was this helpful? React with 👍 or 👎 to provide feedback.
| // No cause-tree evidence; interpret falls back to v1 symptoms. | ||
| evidence: EMPTY_EVIDENCE, | ||
| // This path has no pipeline heartbeat, and run activity is not one. | ||
| telemetryLastTs: null, |
There was a problem hiding this comment.
🔍 Snapshot path no longer reports run activity as telemetry freshness
SnapshotFlowSource now returns telemetryLastTs: null unconditionally, where it previously returned freshestTs(ctx.liveScalar.last_activity). That is a deliberate semantic change (run activity is not a pipeline heartbeat, and the new test asserts it), but it has a knock-on effect worth being explicit about: on the snapshot path liveness is now always freshness_unknown, which makes facts.trustworthy always false there (assessHealth sets trustworthy: !telemetryStale && telemetry !== "none" && !flowUnmeasured).
So every environment still on the snapshot fallback — i.e. any env whose env_metrics pipeline hasn't populated yet — now serves a report flagged untrustworthy, which the new report layout renders with a ⚑ stale data badge and the "informational only" caveat. That may read as alarming for a brand-new environment that is simply young. Worth confirming this is the intended reader experience for the rollout period.
Was this helpful? React with 👍 or 👎 to provide feedback.
| "cadence_minutes" integer GENERATED ALWAYS AS (((spec ->> 'checkEveryMinutes')::int)) STORED | ||
| ); | ||
| --> statement-breakpoint | ||
| ALTER TABLE "trigger_dashboard_agent"."chats" DROP COLUMN IF EXISTS "messages"; |
There was a problem hiding this comment.
🔴 Existing agent conversations lose their entire message history
The stored conversation text is deleted (DROP COLUMN IF EXISTS "messages" at internal-packages/dashboard-agent-db/drizzle/0002_watches_and_chat_messages.sql:89) without first copying it into the new per-message table, so every conversation that already exists comes back empty.
Impact: Anyone who had already used the assistant sees their past conversations listed but with nothing in them, permanently.
Why the transcript is unrecoverable after this migration
Migrations 0000/0001 created trigger_dashboard_agent.chats.messages (a JSONB array holding the whole transcript — see the pre-PR README description). Migration 0002 creates chat_messages and then drops chats.messages with no INSERT INTO chat_messages … SELECT … FROM chats backfill, and sets chats.next_message_position to the default 1 as though every chat were empty.
After deploy, getChatMessages (internal-packages/dashboard-agent-db/src/queries.ts) reads only chat_messages, so it returns [] for every pre-existing chat while listChats still lists the row. The drop is irreversible once applied.
Either add a backfill step that expands the old JSONB array into chat_messages (assigning position by array index and setting next_message_position accordingly), or defer the DROP COLUMN to a later migration.
Prompt for agents
Migration 0002 drops trigger_dashboard_agent.chats.messages (the JSONB transcript created by migrations 0000/0001) in the same migration that introduces the new chat_messages table, with no backfill. After it runs, getChatMessages() reads chat_messages only, so every conversation created before the migration renders as empty, and the original data is gone.
Decide whether pre-existing chats must survive. If they must, add a backfill before the DROP: expand each chats.messages array element into a chat_messages row keyed by (chat_id, message_id) with position = array index + 1 and role read from the message payload, then set chats.next_message_position to the resulting count + 1, and only then drop the column. If they need not survive (feature never deployed anywhere), say so explicitly in the migration and in the dashboard-agent-db README so the deletion is a recorded decision rather than an oversight.
Was this helpful? React with 👍 or 👎 to provide feedback.
| const environments = await $replica.runtimeEnvironment.findMany({ | ||
| where: { | ||
| projectId: project.id, | ||
| ...(scope.scoped ? { id: scope.environmentId } : {}), | ||
| // Only base/parent environments. Branch children (preview branches) | ||
| // are excluded — syncs target the parent and branches override elsewhere. |
There was a problem hiding this comment.
🔍 A delegated token minted for a preview-branch environment lists nothing
resolveUserActorEnvironmentScope narrows the query to id: scope.environmentId, but the existing filter keeps parentEnvironmentId: null. A dashboard-agent token minted for a preview branch child (which the in proxy will happily mint, since findEnvironmentBySlug accepts PREVIEW) therefore matches neither clause and the endpoint returns [] rather than the environment the caller is scoped to. Worth confirming whether preview branches are meant to reach this route at all.
Was this helpful? React with 👍 or 👎 to provide feedback.
… root The queue-JWT test read its route sources through repo-root-relative paths, so it never resolved from the webapp's own working directory.
The scope ceiling rewrite landed here and was reverted two PRs up, leaving the stack asserting both directions. The exchange intersects requested scopes with the token's cap again, a capless token passes through like a PAT, and the route keeps only the environment claim check and the acting client.
The test mocked the old preamble, so the route hit real rbac and a logger without `info`, failing with a 403 and an uncaught type error.
| type DataViewPart = { type: string; data?: { blocks?: unknown[] } }; | ||
|
|
||
| function viewBlocks(message: UIMessage): unknown[] { | ||
| const parts = (message.parts ?? []) as DataViewPart[]; | ||
| return parts.flatMap((part) => | ||
| part.type === "data-view" && Array.isArray(part.data?.blocks) ? part.data!.blocks! : [] | ||
| ); | ||
| } | ||
|
|
There was a problem hiding this comment.
🔴 Long chats can end up with a duplicate investigation card for the same question
When a long conversation is shortened, the code that preserves an unfinished investigation looks for the wrong kind of transcript entry (part.type === "data-view" at internal-packages/dashboard-agent/src/compaction.ts:117), so it never finds one and the investigation's identity is dropped.
Impact: After a long conversation is summarised, the agent loses the id of the investigation it is working on and opens a second card for the same question instead of updating the first.
Where the two readers disagree on the stored part shape
Every investigation card is written into the transcript as a tool-result part: investigationSettlementMessage builds { type: "tool-render_view", state: "output-available", output: { blocks: [...] } } (internal-packages/dashboard-agent-db/src/queries.ts:788-796), and the agent's own reader cardsInMessage matches exactly that (internal-packages/dashboard-agent/src/agent-runtime.ts:210-214, typed.type !== "tool-render_view" || !Array.isArray(typed.output?.blocks)). The webapp's winning-revision logic in apps/webapp/test/dashboard-agent.test.ts:320-323 matches the same shape.
compaction.ts's viewBlocks instead matches part.type === "data-view" and reads part.data.blocks. Nothing in this PR ever emits that shape, so collectDurableState returns { investigations: [] } for every real transcript, describeDurableState returns undefined, and both buildCompactedModelMessages and withDurableState become no-ops. The only reason compaction.test.ts passes is that its investigationMessage fixture hand-builds a data-view part rather than the shape the store writes.
The consequence is precisely the failure the module documents at the top of the file: the model loses the investigationId across the summary boundary and opens a SECOND card for the same question.
| type DataViewPart = { type: string; data?: { blocks?: unknown[] } }; | |
| function viewBlocks(message: UIMessage): unknown[] { | |
| const parts = (message.parts ?? []) as DataViewPart[]; | |
| return parts.flatMap((part) => | |
| part.type === "data-view" && Array.isArray(part.data?.blocks) ? part.data!.blocks! : [] | |
| ); | |
| } | |
| type ViewToolPart = { type: string; output?: { blocks?: unknown[] } }; | |
| function viewBlocks(message: UIMessage): unknown[] { | |
| const parts = (message.parts ?? []) as ViewToolPart[]; | |
| return parts.flatMap((part) => | |
| part.type === "tool-render_view" && Array.isArray(part.output?.blocks) | |
| ? part.output!.blocks! | |
| : [] | |
| ); | |
| } |
Was this helpful? React with 👍 or 👎 to provide feedback.
| bucketIntervalMs: bucketSeconds * 1000, | ||
| // Oldest first; buckets with no sample are omitted, so gaps carry the previous depth. | ||
| depthTrend: (trendRows ?? []) | ||
| .slice() | ||
| .sort((a, b) => a.bucket.localeCompare(b.bucket)) | ||
| .map((row) => row.depth), |
There was a problem hiding this comment.
🔍 depthTrend omits empty buckets while advertising a fixed bucket interval
The response pairs bucketIntervalMs with a depthTrend array built by sorting and mapping only the rows ClickHouse returned. A bucket with no sample is dropped rather than carry-forward filled, so any consumer that reconstructs timestamps as from + i * bucketIntervalMs (which is exactly what MiniLineChart's bucketStartMs/bucketIntervalMs props do) will misplace every point after the first gap. readClickhouseSignals in waitingRunDiagnosis.server.ts:138-146 does carry-forward fill for the same data, so the two readers of depthSparklines disagree. Worth aligning before the UI PR consumes this endpoint.
Was this helpful? React with 👍 or 👎 to provide feedback.
| const requested = target.requestedEnvironmentSlugs; | ||
| if (requested && (requested.length !== 1 || requested[0] !== environment.slug)) { | ||
| throw forbiddenEnvironment(`This token is scoped to the "${environment.slug}" environment.`); | ||
| } |
There was a problem hiding this comment.
🔍 Environment-scoped run listing refuses the public "staging" alias
resolveUserActorEnvironmentScope compares requestedEnvironmentSlugs against the raw RuntimeEnvironment.slug, which is stg for staging. Elsewhere the API deliberately accepts the public alias and maps it (resolveEnvironmentForAuthentication does if (slug === "staging") slug = "stg"). So an environment-scoped delegated token calling /projects/:ref/runs?filter[env]=staging against its own staging environment gets a 403 rather than its own runs. Only reachable for a token minted for a staging environment, but the mismatch is real.
Was this helpful? React with 👍 or 👎 to provide feedback.
| if (period) sp.append("period", period); | ||
| // Double-encoded: a task queue's ClickHouse name carries a `task/` prefix, and | ||
| // the route un-escapes `%2F` back to `/` itself. | ||
| const result = await envApiGet( | ||
| `/api/v1/queues/${encodeURIComponent(queue)}/metrics?${sp.toString()}` | ||
| ); |
There was a problem hiding this comment.
🔍 get_queue comment claims double-encoding that the code doesn't do
The comment says the queue name is "double-encoded" because the route un-escapes %2F back to /, but the call only does a single encodeURIComponent(queue). For a plain task id that's fine (the route adds the task/ prefix itself), but for type: "custom" with a name containing / the single encoding produces %2F, which the route's .replace(/%2F/g, "/") turns back into a path separator — so the comment and the code disagree about which layer owns the escaping. Worth a second look with a custom queue name that contains a slash.
Was this helpful? React with 👍 or 👎 to provide feedback.
| const totals = totalsRows[0]; | ||
| // Zero means measured none; no rows means unmeasured. | ||
| const dlqDelta = totals !== undefined ? Math.round(num(totals.dlq_total)) : null; |
There was a problem hiding this comment.
🔍 queueTotalsQuery returning a NULL-sum row is read as a measured zero
sum(dlq) over an empty subquery still returns one row, with NULL. totals !== undefined is therefore true and num(totals.dlq_total) coerces to 0, so dlqDelta becomes a measured none and the report can emit the "nothing dead-lettered" observation for an environment where dead-letter volume was never measured. The same applies to total_queued, which then suppresses worst-queue attribution rather than reporting it as unmeasured. This is pre-existing behaviour carried over from dlqTotalQuery, but the new comment ("Zero means measured none; no rows means unmeasured") states a guarantee the query shape doesn't provide.
Was this helpful? React with 👍 or 👎 to provide feedback.
… nothing
assertUserActorScope returned early whenever the passed scope carried no
org, project or environment, and the route builder passes {} for any route
that declares no context — so the guard was a no-op there. api.v1.orgs's
action is such a route and has no authorization block either, letting a
read-only agent token create an organization.
Fail closed instead, with an explicit identityOnly opt-in for the two
contextless loaders that answer with the caller's own identity, and give
org creation the gate its siblings have.
list_environments, get_run, get_run_trace and get_error interpolated a bare z.string() straight into the request path, so a model-chosen id could steer the call at another same-origin route.
ask_support defaulted its URL to localhost and gated only on the secret, so with the secret set and the URL unset the user's question and the bearer secret went to a local port inside the agent's container.
…l judge The shape descriptor for a redacted object copied its key names verbatim, so a payload keyed by an email address sent that address to the judge model and into the chat_turn_evals row. Emit a count instead, in both the shape and the depth-cap descriptor, and stop allow-listing "keys" so a tool's own field of that name is redacted like any other.
The route served a deployment's git blob — commit message, author, branch, PR title — with no ability check, while the deployments list serves the same blob behind read on deployments. Apply that check here too.
| function metricDelta(metric: LayoutMetricInput): LayoutDelta | undefined { | ||
| const delta = metric.delta; | ||
| if (delta && delta.mult !== undefined && delta.mult > 1 && delta.dir !== "flat") { | ||
| return { | ||
| text: `${delta.dir === "up" ? REPORT_GLYPH.up : REPORT_GLYPH.down} ${delta.mult}×`, | ||
| dir: delta.dir, | ||
| }; | ||
| } | ||
| return metric.normal === undefined | ||
| ? undefined | ||
| : { text: `${REPORT_GLYPH.flat} flat`, dir: "flat" }; | ||
| } |
There was a problem hiding this comment.
🔍 A metric that fell against its baseline now renders as "flat"
metricDelta only emits a direction when mult > 1, so any metric with a baseline whose multiplier rounds to 0× or 1× renders → flat — including a genuine drop (dir: "down"). The previous deltaSegment in renderMarkdown.ts emitted a bare ↓ for exactly that case, deliberately ("a drop rounds to 0×/1×, meaningless — the arrow already says 'below normal'"). The new behaviour actively asserts "flat" for a metric that halved, which reads as a stronger claim than the old arrow-only rendering. The doc comment states the intent, so this is a judgement call rather than an obvious defect, but it is a semantic change to what the report tells users.
Was this helpful? React with 👍 or 👎 to provide feedback.
2 participants
The system behind the dashboard agent: everything except the UI, which follows in #4529
The agent reads runs, errors, queues, deploys and health through the public API with a delegated, read-only user token. It has no database access of its own beyond its conversation store.
Structure
Each layer only knows the one above it. The UI PR sits on top and knows all four.
System-level changes
userActorEnvironment.server.ts) enforces it; routes call it rather than deriving the rule.img-srcdrops its wildcard.Notes
canAccessDashboardAgent; no behavior change with the flag off.@trigger.dev/core(report schemas) — see the changeset.