Global unhandled promise rejection handler is configured
Why it matters
Unhandled promise rejections are silent killers. In Node.js prior to v15, they produced no output and leaked memory. In modern runtimes they terminate the process, causing unannounced restarts. In browsers, they leave background operations in an unknown state with no user feedback. CWE-703 (improper check for exceptional conditions) applies directly. Without a global handler, async errors from queued jobs, scheduled tasks, or deferred operations vanish entirely — producing outages with no trace in logs and no signal in error tracking.
Severity rationale
High because unhandled rejections terminate Node.js processes without warning or logging, causing unannounced service restarts with zero diagnostic trail.
Remediation
Register global rejection handlers in your app's entry point, before any async code runs. Both browser and Node.js surfaces need coverage.
// app/layout.tsx or lib/error-handlers.ts
if (typeof window !== 'undefined') {
window.addEventListener('unhandledrejection', (event) => {
// Send to error tracking before preventing default
reportError(event.reason)
event.preventDefault()
})
}
// server entry point
process.on('unhandledRejection', (reason) => {
logger.error({ reason }, 'Unhandled promise rejection')
// Do NOT exit — let the process continue unless reason is catastrophic
})
The handler must call into your error tracking service (Sentry, Datadog, etc.), not just console.error, for the check to pass.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Error Resilience Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- cwe · CWE-703 — Improper Check or Handling of Exceptional Conditions
- iso-25010:2011 · reliability.fault-tolerance
Taxons
History
- 2026-04-18·v1.0.0·Initial import from error-resilience·automated