Problem Statement
A user pointed out that when a Node.js error is thrown with a cause (e.g. throw new CustomError(message, { cause: originalError })), Sentry always surfaces the outermost wrapper error in issue titles, alerts, and crash locations. The inner cause, which is often the most actionable part of the failure is buried.
Sentry already handles this for React 19 errors, RxJava, and Kotlin Coroutines via main_exception_id overrides in _maybe_override_main_exception_id(). But there is no equivalent for generic Node.js cause chains, which are a very common pattern.
Solution Brainstorm
Extend the existing main_exception_id override mechanism to recognize generic Node.js cause chains and treat the cause as the primary exception, similar to how it's already done for React, RxJava, and Kotlin.
Product Area
Issues
Problem Statement
A user pointed out that when a Node.js error is thrown with a cause (e.g. throw new CustomError(message, { cause: originalError })), Sentry always surfaces the outermost wrapper error in issue titles, alerts, and crash locations. The inner cause, which is often the most actionable part of the failure is buried.
Sentry already handles this for React 19 errors, RxJava, and Kotlin Coroutines via
main_exception_idoverrides in_maybe_override_main_exception_id(). But there is no equivalent for generic Node.jscausechains, which are a very common pattern.Solution Brainstorm
Extend the existing main_exception_id override mechanism to recognize generic Node.js cause chains and treat the cause as the primary exception, similar to how it's already done for React, RxJava, and Kotlin.
Product Area
Issues