Improved Error Investigations: User Identity Now Set in Sentry

Release: v1.0.412 · Error Monitoring

Background

When an error is captured in the platform, captureError() sends the event to Sentry with structured tags — including the affected domain, organisation ID, and operation name. Until now, one critical piece of context was missing: who the error happened to.

Without a user identity on the Sentry scope, it was not possible to:

• Search Sentry for all errors encountered by a specific user.
• Spot patterns where the same user is repeatedly hitting the same failure.
• Efficiently triage a user-reported issue by locating their specific Sentry events.

This release resolves that gap.

What Changed

Optional userId on CaptureErrorOptions

captureError() now accepts an optional userId field in its options object:

captureError(error, {
  domain: 'submissions',
  orgId: org.id,
  operation: 'quarterly-submission',
  userId: user.id,          // <-- new
});

When userId is supplied, captureError() calls scope.setUser({ id: userId }) before the exception is sent to Sentry. When it is omitted, behaviour is identical to before — no user context is set and no errors are thrown.

Where to pass userId

Any call site that already has user context in scope should now forward it. The two most common locations are:

Call site	Context available
tRPC procedures	ctx.user.id from the authenticated session
Inngest functions	userId from the function's event payload or step data

PII scrubbing is unaffected

The platform's beforeSend hook scrubs personally identifiable information before events leave the application. UUID-format user IDs (the format used throughout this platform) are not classified as PII-sensitive in the Sentry context and will not be removed by the scrubber. Sentry's own data handling treats the user.id field as an identifier, not as raw personal data.

Impact on Sentry Workflows

Once userId values start appearing on events, Sentry's user-centric views become useful:

• User search — Look up all events for a given user.id directly in the Sentry issue stream.
• Affected users count — Issue cards now show how many distinct users have hit a given error.
• User-based alerts — Alert rules can be scoped to trigger when a threshold of unique users is affected.
• Replays & traces — Sentry Session Replay and distributed traces can be filtered by user ID for end-to-end debugging.

Summary

This is a targeted, low-risk improvement to error observability. The change is fully backwards-compatible — userId is optional and existing call sites that do not yet pass it continue to work without modification. Teams investigating user-reported issues should update their tRPC and Inngest call sites to pass userId to captureError() to take full advantage of the new user-level filtering in Sentry.