You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
commit 9fcc529
Author: Cormac Relf <[email protected]>
Date: Mon Apr 14 17:36:07 2025 +1000
Improve db_pools init: do not crash if DB unavailable during startup
## Why?
When using `Pool::connect[_with]`, sqlx attempts to connect to the given
database immediately, and the fairing will fail if there are any
problems in that attempt (beyond obvious configuration problems that are
found before hitting the network), e.g.:
- the database is unavailable; or
- the username/password is incorrect; or
- the ssl configuration is invalid; or
- any other connection issue.
There are a few pros and cons to this approach:
Pros:
- In development, configuration errors are surfaced slightly faster
Cons:
- Databases are expected to be unavailable sometimes. It does not
normally crash a server if one becomes unavailable after startup,
so why should it prevent a server from starting at all? See
[deadpool's justification]{https://docs.rs/deadpool} for not crashing.
- In production/testing, slower to debug configuration or networking
errors as your edit-test loop now involves restarting an application
rather than refreshing a page or trying a request again.
- Causes database or configuration issues to appear as "failed
deployments" in standard deployment scenarios.
- Introduces hard ordering constraints on operator actions during
database recovery, requiring reboots to follow a functioning database
or applications not to be restarted at certain times
## Effect of change
The sqlx backend now behaves like the deadpool backend: no connection
issues are surfaced during startup. You will not see them until you
attempt to get a connection from the pool. That means rocket will launch
and you can find problems like these in smoke tests.
0 commit comments