fix(webapp): reuse the primary db pool for legacy run-ops when DSNs match#4253
Conversation
…atch When the run-ops split is enabled, the legacy run-ops Prisma client was always built as its own connection pool, even when it targeted the same physical database as the primary (control-plane) client. Where those DSNs resolve to the same database, that opened a second, redundant pool and doubled the connections used against that database. Reuse the primary client by reference when the legacy and primary DSNs resolve to the same database (host, port, database name, user), and only build a separate legacy pool when they genuinely differ.
|
WalkthroughRun-ops topology selection now compares effective legacy and control-plane database targets. When they match, legacy run-ops reuse the control-plane clients; otherwise, independent legacy clients are created. A separate environment setting controls the new run-ops replica connection limit. Tests cover URL comparison, aliasing, independent clients, PostgreSQL queries, and cleanup. Documentation records the shared-pool behavior. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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 |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
2 participants
Summary
When the run-ops split is enabled, the legacy run-ops database client was always constructed as its own connection pool, even when it points at the same database as the primary (control-plane) client. On setups where those two DSNs resolve to the same physical database, this opened a second, redundant pool and doubled the number of connections used against that database. This change makes the legacy client reuse the primary client's pool whenever their DSNs point at the same database, and only open a separate pool when they genuinely differ.
Fix
A small
sameDatabaseTargetcomparison (host, port, database name, user) decides whether the legacy DSN points at the same database as the primary. When it does, the legacy handle reuses the primary client by reference, so no second pool is opened. When the DSNs diverge, the legacy client is built independently as before, so the split still works once the databases are actually separate.Two smaller changes ride along:
Verification
Booted the webapp end-to-end in three modes and confirmed the pools opened as expected via the client's own startup logs and live backend connection counts: split off (single pool), split on with a shared database (legacy reuses the primary pool, no doubling), and split on with separate databases (legacy opens its own pool).