Preserved database error details may disclose sensitive data
Source references: 3The guide requires preservation of the original database code and message, and its example also copies detail, column, and hint. Depending on the database, detail can contain schema information, constraint names, or actual conflicting field values.
If an application exposes P2039 or adapter exceptions to untrusted clients, or exports full production logs to a third party, user data and database internals could be disclosed through error text.
The guide explicitly requires preserving the database's original error message and copies detail, column, and hint for unmapped PostgreSQL errors. If an application returns these errors to untrusted clients, records them in logs accessible to lower-privileged users, or exposes the fields through P2039, schema details, constraint names, and values potentially present in detail could leak. This serves a legitimate diagnostic purpose and does not prove leakage occurred. Users can ask which fields cross API or logging boundaries and require redaction and access controls there while retaining protected diagnostic data internally.
For database errors, preserve `originalCode` and `originalMessage` even when falling back to the provider-specific raw variant:Show 2 other places
} return { kind: 'postgres', code: String(error.code ?? 'N/A'), severity: error.severity ?? 'N/A', message: error.message, detail: error.detail, column: error.column, hint: error.hint, }Prisma uses preserved original details when an unmapped driver error becomes `P2039`. Do not replace every unknown exception with a fabricated `GenericJs` id; rethrow genuinely unexpected non-driver errors so programming bugs remain visible.