|
| 1 | +import { Prisma } from "@trigger.dev/database"; |
| 2 | + |
| 3 | +// Prisma connectivity / infrastructure error codes — engine- and |
| 4 | +// connection-level failures, not query- or validation-level ones. When the |
| 5 | +// database is unreachable, Prisma 6.x throws a PrismaClientKnownRequestError |
| 6 | +// carrying one of these codes (e.g. P1001 "Can't reach database server"). |
| 7 | +const INFRASTRUCTURE_PRISMA_CODES = new Set([ |
| 8 | + "P1001", // Can't reach database server |
| 9 | + "P1002", // Database server reached but timed out |
| 10 | + "P1008", // Operations timed out |
| 11 | + "P1017", // Server has closed the connection |
| 12 | +]); |
| 13 | + |
| 14 | +/** |
| 15 | + * True when `error` is a Prisma infrastructure/connectivity failure (DB |
| 16 | + * unreachable, timed out, connection dropped) rather than a query- or |
| 17 | + * validation-level error. |
| 18 | + * |
| 19 | + * These errors carry internal infrastructure detail (e.g. the database |
| 20 | + * hostname) in their `.message`, so they must never be surfaced to API |
| 21 | + * clients — callers should let them propagate to the generic 5xx handler |
| 22 | + * (which both scrubs the message and is retryable by the SDK) instead of |
| 23 | + * folding `.message` into a client-facing error. |
| 24 | + */ |
| 25 | +export function isInfrastructureError(error: unknown): boolean { |
| 26 | + if ( |
| 27 | + error instanceof Prisma.PrismaClientInitializationError || |
| 28 | + error instanceof Prisma.PrismaClientRustPanicError || |
| 29 | + error instanceof Prisma.PrismaClientUnknownRequestError |
| 30 | + ) { |
| 31 | + return true; |
| 32 | + } |
| 33 | + |
| 34 | + if (error instanceof Prisma.PrismaClientKnownRequestError) { |
| 35 | + return INFRASTRUCTURE_PRISMA_CODES.has(error.code); |
| 36 | + } |
| 37 | + |
| 38 | + return false; |
| 39 | +} |
0 commit comments