[ggivo]

What

When you get a Connection from a TrackingConnectionPool (i.e., every MultiDbClient database), it was being initialized twice: once by Connection.Builder.build(), and a second time by FailFastConnectionFactory.makeObject().

Two visible effects, per pooled connection:

• An extra HELLO/CLIENT round-trip on the wire.
• The default PUBSUB_CONSUMER registered twice on the push-consumer chain.

Present since v7.0.0.

Why it happened

Connection.Builder.build() has always initialized the connection it returns. The pool factory then ran initialization a second time on top, after super.makeObject() had already done it.

Fix

Split construction from initialization so the pool factory can interpose without re-initializing:

• New protected createConnection() hook on Connection.Builder — subclasses (e.g. CacheConnection.Builder) override this to pick the concrete type.
• Package-private buildUninitialized() lets ConnectionFactory build without auto-init.
• ConnectionFactory exposes a protected initialize() hook that FailFastConnectionFactory overrides to wrap the (now sole) init in its existing tracking — which, as a side benefit, finally makes forceDisconnect() able to interrupt a connection mid-handshake.

Public API is unchanged.

Tests

New TrackingConnectionPoolInitTest checks that a pool-obtained connection has exactly one PUBSUB_CONSUMER registered. Fails on the buggy version, passes here.

Follow-up

Connection.initializeFromClientConfig() has no out-of-package caller after this — its visibility can be tightened in a separate PR for the next major release.

---

Note

Medium Risk
Touches core connection pooling and handshake initialization paths used by MultiDbClient; behavior fix is targeted but affects every pooled connection lifecycle.

Overview
Fixes double initialization of pooled Connection instances from TrackingConnectionPool (used by multi-DB clients): Connection.Builder.build() and the pool factory both ran initializeFromClientConfig(), causing an extra HELLO/CLIENT handshake and duplicate PUBSUB_CONSUMER registration.

Construction vs initialization is split without changing public build() behavior: Connection.Builder adds createConnection() (subclass hook, e.g. CacheConnection) and package-private buildUninitialized(); ConnectionFactory builds uninitialized connections and calls a new protected initialize() that runs init once.

FailFastConnectionFactory drops the second init in makeObject() and overrides initialize() to add/remove connections in factoryTrackedObjects during the sole init, so forceDisconnect() can interrupt in-flight HELLO/AUTH/CLIENT handshakes.

Adds TrackingConnectionPoolInitTest to assert single init and a single pub/sub push consumer on borrowed connections.

^{Reviewed by Cursor Bugbot for commit 3d1b06b. Bugbot is set up for automated code reviews on this repo. Configure here.}

[github-actions]

Test Results

  203 files  ±0    203 suites  ±0   9m 28s ⏱️ +17s
7 767 tests ±0  7 108 ✅  - 597  659 💤 +597  0 ❌ ±0 
7 787 runs  ±0  7 128 ✅  - 597  659 💤 +597  0 ❌ ±0 

Results for commit 3d1b06b. ± Comparison against base commit c9f05c2.

This pull request skips 597 tests.

redis.clients.jedis.commands.commandobjects.CommandObjectsArrayCommandsTest[1] ‑ testArcountMissingKey()[1]
redis.clients.jedis.commands.commandobjects.CommandObjectsArrayCommandsTest[1] ‑ testArcountMissingKeyBinary()[1]
redis.clients.jedis.commands.commandobjects.CommandObjectsArrayCommandsTest[1] ‑ testArdel()[1]
redis.clients.jedis.commands.commandobjects.CommandObjectsArrayCommandsTest[1] ‑ testArdelBinary()[1]
redis.clients.jedis.commands.commandobjects.CommandObjectsArrayCommandsTest[1] ‑ testArdelrange()[1]
redis.clients.jedis.commands.commandobjects.CommandObjectsArrayCommandsTest[1] ‑ testArdelrangeBinary()[1]
redis.clients.jedis.commands.commandobjects.CommandObjectsArrayCommandsTest[1] ‑ testArget()[1]
redis.clients.jedis.commands.commandobjects.CommandObjectsArrayCommandsTest[1] ‑ testArgetBinary()[1]
redis.clients.jedis.commands.commandobjects.CommandObjectsArrayCommandsTest[1] ‑ testArgetrange()[1]
redis.clients.jedis.commands.commandobjects.CommandObjectsArrayCommandsTest[1] ‑ testArgetrangeBinary()[1]
…

♻️ This comment has been updated with latest results.

[jit-ci]

🛡️ Jit Security Scan Results

✅ No security findings were detected in this PR

---

^{Security scan by Jit}

[uglide]

LGTM

[atakavci]

Looks good in terms of functionality and consistent with existing behaviour.
i have no comments other than the one related to the way we are changing the design and responsibilities. The factory is kind of taking on the role of builder.
Plus, i like to stay away from changing core types(as much as possible) for specific client setup.
Right now i am trying to explore the ways if we can achieve this with changes limited to MultiDb.

[atakavci]

this build() gets no use anymore.