feat(quaint): expose pool health check options as connection string parameters - #5846
feat(quaint): expose pool health check options as connection string parameters#5846YuzuruS wants to merge 1 commit into
Conversation
…arams The pooled Quaint builder has long supported test_on_check_out and health_check_interval (wired through mobc, with QuaintManager::check already implemented as a SELECT 1 ping), but neither option was parseable from a connection string. Since Prisma constructs the pool exclusively via Quaint::builder_with_tracing from the datasource URL, the health check machinery was effectively unreachable for Prisma users. This exposes both options as connection string parameters for the PostgreSQL, MySQL and SQL Server connectors, following the exact pattern of the existing max_connection_lifetime and max_idle_connection_lifetime parameters: - test_on_check_out (true/false, default false): verify a connection with a lightweight SELECT 1 before handing it out of the pool, so connections that were silently severed while idle (NAT/LB idle timeouts, server-side resets) are discarded and replaced instead of failing the query with a connection error. - health_check_interval (seconds): rate-limits the check to at most once per interval per connection; 0 or omitted checks every checkout. SQL Server accepts both camelCase (testOnCheckOut, healthCheckInterval) and snake_case spellings, consistent with its other JDBC-style parameters. Long-running deployments (ECS/Fargate, EC2, Kubernetes) are the main beneficiaries: unlike short-lived serverless invocations, their pools hold connections long enough to hit idle disconnects, which currently surface as intermittent P1001/P1017 errors. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SaXrs7mjAi4BdWYXQC5HZ4
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
Summary by CodeRabbit
WalkthroughMySQL, PostgreSQL, and MSSQL connection URL parsers now support checkout testing and health-check interval parameters. The settings default to disabled, with a zero interval represented as no interval. New accessors expose the parsed values. Pool builder construction reads these settings for the three connectors and applies them, while pooled connection documentation describes the parameters and SQLite limitation. Tests cover provided values, defaults, and zero-interval behavior. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Overview
The pooled
Builderhas long supportedtest_on_check_outandhealth_check_interval, andQuaintManager::checkis already implemented as aSELECT 1ping — but no connector URL parser exposes either option. Since Prisma builds its pool exclusively from the datasource URL viaQuaint::builder_with_tracing, the health-check machinery is effectively dead code for Prisma users.This PR makes both options parseable from the connection string for PostgreSQL, MySQL and SQL Server, following the exact pattern of the existing
max_connection_lifetime/max_idle_connection_lifetimeparameters.New parameters
test_on_check_outfalsetrue, a connection is verified withSELECT 1before being handed out of the pool. A connection that was silently severed while idle (NAT/LB idle timeout, server-side reset) is discarded and transparently replaced instead of failing the query with a connection error.health_check_intervaltest_on_check_out=true: rate-limits the check to at most once per interval per connection (mobc marks the connection checked).0or omitted = verify every checkout.SQL Server also accepts
testOnCheckOut/healthCheckInterval, consistent with its other JDBC-style parameters (keys are case-normalized by the JDBC parser).SQLite is intentionally excluded: an embedded file database has no network path that can go stale.
Why
Long-running deployments (ECS/Fargate, EC2, Kubernetes) hold pooled connections long enough for middleboxes or the server to sever them while idle. The next checkout hands out a dead connection and the query fails with an intermittent, hard-to-reproduce
P1001/P1017— the recurring theme behind reports like prisma/prisma#13770. Borrow-time validation is the standard remedy in every mainstream pool (HikariCPconnectionTestQuery, pgbouncerserver_check_query, tarn/knexafterCreatevalidation, etc.); quaint already has the mechanism, it just cannot be switched on.Companion issue with a fully-correlated production trace (app logs + RDS
system_healthExtended Events): prisma/prisma#29786Changes
quaint/src/connector/postgres/url.rs— parse both params + gettersquaint/src/connector/mysql/url.rs— parse both params + gettersquaint/src/connector/mssql/url.rs— parse both params (camelCase + snake_case) + gettersquaint/src/pooled.rs— wire both params into theBuilderinbuilder_with_tracingfor the three connectors; document the parameters in the module docsNo behavior change for existing connection strings (both options default to off;
Builderdefaults are untouched).Testing
0interval normalization, and mssql camelCase/snake_case spellingscargo test -p quaint --features "pooled,all-native" --lib health_check→ 10 passedcargo clippy -p quaint --features "pooled,all-native"→ no warningscargo fmtclean