fix(core,webapp): redact sensitive fields in logs by default and cap their size - #4401
fix(core,webapp): redact sensitive fields in logs by default and cap their size#4401carderne wants to merge 5 commits into
Conversation
…their size The Logger used to only redact keys a caller explicitly listed, and most call sites listed none. It now applies a default set of sensitive key names (tokens, passwords, api keys, payloads, headers, email, and more) to every log line, matched case-insensitively and recursively, no matter how many arguments a log call passes. String values shaped like a bearer token or API key are redacted even under an unlisted key. Logged errors now run their message, stack and metadata through the same redaction and size limits as the rest of the line, instead of being copied through untouched. Long strings and large arrays are truncated with a marker instead of written out in full. The webapp's Sentry reporting now applies the same redaction to the extra data it sends, so a field that gets filtered on stdout is filtered on its way to Sentry too.
🦋 Changeset detectedLatest commit: fb88613 The changes in this PR will be included in the next version bump. This PR includes changesets to release 26 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:
WalkthroughThe logging system now applies default and caller-provided key filtering, secret-pattern detection, string and array truncation, and recursion limits. Structured errors use the same redaction pipeline for messages, stacks, metadata, and nested errors. The webapp’s Sentry error-reporting path redacts flattened log arguments before sending exception or message payloads. Tests cover logger output, the standalone 🚥 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 |
@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: |
There was a problem hiding this comment.
🔍 Primary log message is redacted inconsistently between the two loggers
In Logger.#structuredLog (packages/core/src/logger.ts:121-134) the primary message argument is placed directly into the structured log and never passed through filterKeys, so a secret embedded in the message string itself (e.g. logger.info("token tr_live_...")) is logged verbatim. In contrast, SimpleStructuredLogger.#structuredLog (packages/core/src/v3/utils/structuredLogger.ts:95-102) wraps the whole object — including message — in redact, so its primary message IS redacted. This is an inconsistency between the two loggers. Only the structured $message (from an args message key) and error message/stack/metadata are redacted in Logger. Not flagged as a bug because the pre-existing behavior for the primary message was also unredacted and the PR focuses on structured fields, but worth confirming it matches intent.
(Refers to line 127)
Was this helpful? React with 👍 or 👎 to provide feedback.
| const extra = redact(flattenArgs(args), SENTRY_EXTRA_FILTERED_KEYS) as Record<string, unknown>; | ||
|
|
||
| if (error) { | ||
| captureException(error, { | ||
| captureException(redactError(error), { | ||
| extra: { | ||
| message, | ||
| ...flattenArgs(args), | ||
| ...extra, | ||
| }, | ||
| }); | ||
| } else { |
There was a problem hiding this comment.
🔍 Captured Sentry extra still carries the raw Error object
On the captureException path in apps/webapp/app/services/logger.server.ts:23-30, extra is built from redact(flattenArgs(args), ...), which still contains the original error key (an Error instance). redact leaves the Error mostly untouched (Error message/stack are non-enumerable, so Object.entries yields nothing and the instance is returned unchanged). While the captured exception itself is redacted via redactError, the error entry inside extra is the un-redacted Error. In practice JSON.stringify(Error) serializes to {}, so the message/stack usually don't leak through the extra field, but Sentry's own serialization of Error objects could differ. Worth confirming Sentry doesn't surface the raw message/stack via the extra payload.
Was this helpful? React with 👍 or 👎 to provide feedback.
Summary
Structured logs now redact common credential and sensitive-data fields by
default, including nested values and error metadata. Long strings and arrays
are capped so a single log entry cannot grow without bound.
The same redaction applies to error-reporting extras. Unchanged values retain
their existing references, avoiding unnecessary cloning on ordinary log calls.