fix(webapp,clickhouse): stop invalid customer queries alerting, and isolate Sentry scope per request#4372
Conversation
|
WalkthroughOpenTelemetry now installs SentryContextManager for enabled and disabled tracing, preserving isolation scopes across concurrent requests. New tests cover scope leakage and isolation behavior. ClickHouse query methods classify quota errors as warnings, accept additional logging fields, and retain errors for other failures. TSQL execution includes query metadata in logs and distinguishes invalid queries from execution failures. Change log entries document both behavior updates. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 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 |
![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.
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 (2)
internal-packages/clickhouse/src/client/client.ts (2)
269-273: 🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick winPropagate
logFieldsthrough everyqueryWithStatsfailure log.
req.logFieldsis only merged in the ClickHouse request-error branch. Parameter-validation and result-schema failures still omit it, so callers lose the originating query metadata despite the new field’s documentation and PR contract.Suggested fix
this.logger.error("Error parsing query params", { + ...req.logFields, name: req.name, error: validParams.error, query: req.query, params, queryId, }); this.logger.error("Error parsing clickhouse query result", { + ...req.logFields, name: req.name, error: parsed.error, query: req.query, params, queryId, });Also applies to: 334-347
474-486: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winClassify errors raised while buffering
queryFastresults.This catch only covers
this.client.query; the subsequentresultSet.stream()loop at Lines 513-533 runs outside it. A quota error raised mid-stream therefore bypasses the warning classification,recordClickhouseError, and error logging entirely. Wrap that loop in the same shared error-handling path used byqueryFastStream.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 85cc8419-6c7b-499e-9977-49a2d4dcccee
📒 Files selected for processing (2)
internal-packages/clickhouse/src/client/client.tsinternal-packages/clickhouse/src/client/tsql.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- internal-packages/clickhouse/src/client/tsql.ts
📜 Review details
⏰ Context from checks skipped due to timeout. (3)
- GitHub Check: code-quality / code-quality
- GitHub Check: Analyze (javascript-typescript)
- GitHub Check: Analyze (actions)
🧰 Additional context used
📓 Path-based instructions (4)
**/*.{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:
internal-packages/clickhouse/src/client/client.ts
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use function declarations instead of default exports
Files:
internal-packages/clickhouse/src/client/client.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:
internal-packages/clickhouse/src/client/client.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/clickhouse/src/client/client.ts
🧠 Learnings (10)
📚 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:
internal-packages/clickhouse/src/client/client.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:
internal-packages/clickhouse/src/client/client.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:
internal-packages/clickhouse/src/client/client.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:
internal-packages/clickhouse/src/client/client.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:
internal-packages/clickhouse/src/client/client.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:
internal-packages/clickhouse/src/client/client.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:
internal-packages/clickhouse/src/client/client.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:
internal-packages/clickhouse/src/client/client.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/clickhouse/src/client/client.ts
📚 Learning: 2026-07-03T09:41:46.517Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 4131
File: internal-packages/metrics-pipeline/src/types.ts:0-0
Timestamp: 2026-07-03T09:41:46.517Z
Learning: When generating ClickHouse `UInt64`-backed ordering keys from epoch-derived values (e.g., `ms` and `seq`), avoid JS `number` arithmetic that can exceed the safe-integer range (2^53). Compute the key using `BigInt` (e.g., `BigInt(ms) * 100000n + BigInt(seq)`) and return it as a `string` (via `.toString()`) to preserve exact ordering. Ensure the corresponding Zod schema for the raw input (e.g., `QueueMetricsRawV1Input.order_key`) accepts/preserves this exact value (typically via `z.union([z.string(), z.number()]).optional()`), so callers can assign the computed value directly into the ClickHouse `UInt64` column without precision loss or misordering.
Applied to files:
internal-packages/clickhouse/src/client/client.ts
🔇 Additional comments (3)
internal-packages/clickhouse/src/client/client.ts (3)
174-186: LGTM!
626-638: LGTM!
1034-1056: 🎯 Functional CorrectnessNo change needed. The quota error set covers memory, timeout/slow query, row, byte, combined row/byte, and cancelled query limits, matching the ClickHouse errors this package’s error type maps use.
…solate Sentry scope per request Three fixes to how query failures are reported. Invalid TSQL is a caller mistake, not ours: executeTSQL now logs ExposedTSQLError at warn and reserves error for InternalTSQLError and unanticipated exceptions, so a bad column name no longer raises an alert. The route above it already returned 400 and logged at warn; the layer below was overriding that decision. ClickHouse rejections that come from a query asking for too much (memory ceiling, timeout, row/byte caps) drop to warn as well. Those are decided in the client, which is the only place holding the parsed ClickHouseError type, and queryWithStats gained a logFields option so a failing query is recorded with the TSQL that generated it rather than the generated SQL alone. Sentry.init runs with skipOpenTelemetrySetup because we register our own OTel pipeline, which also skipped installing SentryContextManager. withIsolationScope only marks the context and relies on that manager to fork, so without it every request shared one global isolation scope and events were attributed to whichever request wrote last. The tracer now registers it, including on the path where tracing is disabled and register() was never called.
…log fields Spread caller-supplied logFields before the canonical ones so a caller cannot overwrite error, query, params, or queryId in a failure log. queryFastStream classifies quota failures the same way the buffered query paths do; a limit hit partway through a stream is still the caller asking for too much. The supplemental EXPLAIN queries carry the originating TSQL too.
The webapp server bundle is ESM and @sentry/remix is CommonJS. Node's loader derives named exports by static analysis, and it does not see SentryContextManager because that name is re-exported transitively from @sentry/node-core. A named import type-checks and bundles, then throws SyntaxError when the server boots. The property is reachable on the default export, which for a CommonJS module is module.exports. Vitest resolves the named import fine, so this only shows up when the built server actually starts.
a9b564d to
539199a
Compare
@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: |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| const CLICKHOUSE_QUOTA_ERROR_TYPES = new Set([ | ||
| "MEMORY_LIMIT_EXCEEDED", | ||
| "TIMEOUT_EXCEEDED", | ||
| "TOO_SLOW", | ||
| "TOO_MANY_ROWS", | ||
| "TOO_MANY_BYTES", | ||
| "TOO_MANY_ROWS_OR_BYTES", | ||
| "QUERY_WAS_CANCELLED", | ||
| ]); |
There was a problem hiding this comment.
🔍 QUERY_WAS_CANCELLED classified as a warn-level quota error
CLICKHOUSE_QUOTA_ERROR_TYPES (internal-packages/clickhouse/src/client/client.ts:1039-1047) includes QUERY_WAS_CANCELLED alongside the memory/timeout/row/byte limits. This is broader than the PR description, which enumerates only MEMORY_LIMIT_EXCEEDED, TIMEOUT_EXCEEDED, TOO_SLOW, and the row/byte caps. A cancellation can arise from client disconnect (cancel_http_readonly_queries_on_client_close: 1 at internal-packages/clickhouse/src/client/client.ts:73), which is legitimately a warn, but server-side cancellations for other reasons would also be demoted to warn and thus escape error alerting. Worth confirming this is intentional.
Was this helpful? React with 👍 or 👎 to provide feedback.
| function createContextManager() { | ||
| return new sentryRemix.SentryContextManager(); | ||
| } |
There was a problem hiding this comment.
🔍 SentryContextManager reached via default (CommonJS) export is unverified from source
createContextManager instantiates new sentryRemix.SentryContextManager() from the default import of @sentry/remix (apps/webapp/app/v3/tracer.server.ts:228-230). Dependencies are not installed in this checkout, so I could not confirm from source that SentryContextManager is present on the default export of @sentry/remix@9.46.0 (it originates in @sentry/opentelemetry). If it is not re-exported on the default object, createContextManager() throws at server boot on both the enabled path (tracer.server.ts:327) and the disabled path (tracer.server.ts:236). The PR adds a dedicated test that constructs it, which should catch this, but it relies on the test environment resolving the same export shape as the running server.
Was this helpful? React with 👍 or 👎 to provide feedback.
1 participant
Summary
A query sent to the query API with a typo in it, like a column name that does not exist, was being reported as a server error. That put customer SQL mistakes into our error alerting, where they made up almost all of the volume on one of our noisiest alerts, and it drowned out the failures that are actually ours to fix. This makes the level match who is at fault, and fixes two related problems found alongside it.
Invalid queries are the caller's, not ours
The query API route already got this right. It checks for
QueryError, logs at warn, and returns a 400, with a comment saying the system handles it gracefully and no alert is needed.The layer underneath ignored that.
executeTSQLlogged every exception out of its catch block at error, including the compile failures the route was about to turn into a 400, and error-level logs are forwarded to error reporting.The TSQL package already draws the line we need:
SyntaxErrorandQueryErrorextend the first. So the catch block now branches onExposedTSQLErrorand logs those at warn, keeping error forInternalTSQLErrorand anything unanticipated, which is a genuine compiler bug.Query limits are also the caller's
The same asymmetry showed up one level down. A query that compiles fine can still be rejected by ClickHouse at execution, and some of those rejections mean the query asked for more than it is allowed to spend rather than that we generated bad SQL.
Those are classified in
ClickhouseClient, because that is the only place holding the parsedClickHouseErrorand its symbolictype. By the time the error reachesexecuteTSQLit has been wrapped and the type is gone, and the type never appears in the message text, so it cannot be recovered by string matching.MEMORY_LIMIT_EXCEEDED,TIMEOUT_EXCEEDED,TOO_SLOW, and the row/byte caps now log at warn. Everything else stays at error.Separately, when one of these queries did fail, the log recorded the generated ClickHouse SQL but not the query the caller actually wrote, which made the reports hard to act on.
queryWithStatstakes an optionallogFieldsthatexecuteTSQLuses to attach the original TSQL.Events were attributed to the wrong request
Chasing the above turned up something broader: only a tenth of the events on that alert pointed at the query API. The rest were pinned to unrelated requests that happened to be in flight at the same time, so the alert looked like the trigger endpoint was failing.
Sentry.initruns withskipOpenTelemetrySetup: true, because we register our own OTel pipeline. That skipsinitOpenTelemetry, and one of the things it does is:The async-context strategy is still installed, but
withIsolationScopeonly marks the OTel context and delegates the actual fork to that context manager:provider.register()installed a plainAsyncLocalStorageContextManager, which does not know that key. The lookup found no scopes on the context and fell back to the process-global default isolation scope, so every request wrote its request data into the same object and the last writer won.The tracer now registers
SentryContextManager, which subclassesAsyncLocalStorageContextManager, so OTel behaviour is unchanged. It is also registered on the path where tracing is disabled, which previously never calledregister()at all and so had no context manager of its own.Tenant tags were always correct, because those come from our own async local storage rather than the isolation scope. That is why the attribution being wrong was not obvious.
This affects every error report the webapp sends, not just the query API.
Verification
internal-packages/clickhouse: 66 tests pass, including four new ones covering each level decision against a real ClickHouse container, one of which drives an actual limit breach withmax_rows_to_read.The isolation fix has a test that reproduces the leak before asserting the fix. Two overlapping requests each tag their own isolation scope; with the plain context manager the slower one reads back the other's tag, and with
SentryContextManagereach reads back its own.