Database Packages should not process.exit(1) on a connection failure

[filecage]

Problem Description

The current behaviour of all provided database packages (mongo, postgres, sqlite and vercel-postgres) is to hard fail when the database connection could not be established and end the process with exit code 1:

payload/packages/db-postgres/src/connect.ts

Line 111 in 0a35737

process.exit(1)

payload/packages/db-mongodb/src/connect.ts

Line 105 in 41cff6d

process.exit(1)

payload/packages/db-sqlite/src/connect.ts

Line 39 in 12395e4

process.exit(1)

payload/packages/db-vercel-postgres/src/connect.ts

Line 93 in 0a35737

process.exit(1)

This makes it impossible to handle connection errors in user land and ending the whole nodejs/nextjs process should also be considered a bad practice because it forces the stack into a state of permanent retrying instead of allowing to handle the error gracefully in userland (and, for instance, show an error page or just disable single features on a site if they require a database connection but still be able to serve the static ones that don't require a database connection).

This also creates unnecessary load on a stack by forcing the nodejs app to permanently restart, leaving the whole web application offline while doing so.

Considering that this is not only an issue that occurs during deployment but might also happen when a database fails during normal operation (these things happen), this is a real life issue and the current design of the database packages makes it impossible to handle it correctly (or at least decide how you'd want to handle it).

Suggested Solution

Instead of catching connection errors in the database packages and then exiting the process, all database packages should just pass/throw the error. This allows handling them in userland.

It might be necessary to adjust other consumers of the connect()/init() functions (like Payloads's generate:db-schema script), so they also handle this error gracefully.

I wouldn't necessarily deem this to be a breaking change as the actual behaviour does not change: instead of catching the error and then exiting the process with exit code 1, the error would just bubble up and, if not caught in between, cause nodejs to exit due to an uncaught exception.

This would also make it easier to handle buildtime errors like the one described in #12605 or #11148 (leading to extra steps like the one added to the docs in #12607).