[finding] driver-sql docblocks call non-SQLite pools "roomy (max ≥ 10)" while every factory-built SQL datasource runs at {min:0,max:5} unless it declares a pool

[os-musk]

Observation (docblock accuracy — no behaviour change proposed)

Blocked-by: #14648
Unlock-action: re-check PR #14773

Two docblocks in packages/drivers/driver-sql/src/sql-driver.ts reason about the pool size of non-SQLite dialects using knex's own default:

• :8168 — "…on every non-SQLite dialect, whose roomy pools (max ≥ 10) cannot exhibit the single-connection dead-lock."
• :5871 — "…on Postgres/MySQL a roomy pool (max=10) lets a fresh connection create the table safely."

knex 3.3.0's Client.poolDefaults() is indeed { min: 2, max: 10 } (node_modules/knex/lib/client.js:229-231). But the runtime never composes a SQL datasource at that default. The only production composition site — buildSqlPool in packages/services/service-datasource/src/default-datasource-driver-factory.ts:626-635 — hands every postgres / mysql datasource an explicit pool of { min: 0, max: 5 } unless the datasource declares its own pool block (a default it preserved on purpose since the pre-#4410 hardcode; pinned by default-datasource-driver-factory.test.ts → "keeps the previous defaults when no pool is declared"). The primary datasource behind OS_DATABASE_URL reaches the driver through that same factory (serve.ts → resolveStorageDefinition → DefaultDatasourcePlugin → DatasourceConnectionService → factory create), with config: { url } and no pool.

Measured (2026-09-02, origin/main @ f60ab90ae, built dist, no live database)

factory.create({ driver: 'postgres', config: { url: 'postgres://u:p@127.0.0.1:1/d' } })
 knex config.pool = {"min":0,"max":5,"createTimeoutMillis":15000} tarn live min/max = 0/5
factory.create({ driver: 'mysql', config: { url: 'mysql://u:p@127.0.0.1:1/d' } })
 knex config.pool = {"min":0,"max":5,"createTimeoutMillis":15000} tarn live min/max = 0/5
factory.create({ driver: 'postgres', config: { url: … }, pool: { min: 3, max: 9 } })
 knex config.pool = {"min":3,"max":9,"createTimeoutMillis":15000} tarn live min/max = 3/9

Why it is worth a card

The docblocks tell the next reader a pool size the platform does not run at. The headroom argument at :5871 still holds at max: 5, so nothing is broken — but the same misreading (knex's min 2, max 10 as "today's effective default") reached the body and the triage of #14176, where it changed the shape of the remedy. Correcting the two docblocks to name the factory's {min:0,max:5} (and where that number lives) closes the gap at its source.

Related context (not addressed here): #14176 · #5714 lineage (datasource pool honoured by pg/mysql, rejected on sqlite).

Filed unassigned as an observation from the #14176 seat; triage decides the grade.

Generated by Claude Code

[huangyiirene]

Triage — graded p3, finding cleared, docs, pm:queue, routed domain:engine.

Re-measured at origin/main 2aa8456

Both docblocks moved since your read; both say what you quote:

your line	at 2aa8456	text
:8168	:8204	"…dialect, whose roomy pools (max ≥ 10) cannot exhibit the single-connection…"
:5871	:5901	"…roomy pool (max=10) lets a fresh connection create the table safely."

And buildSqlPool in packages/services/service-datasource/src/default-datasource-driver-factory.ts reads exactly as you describe:

min: typeof pool.min === 'number' ? pool.min : 0,
max: typeof pool.max === 'number' ? pool.max : 5,

with the preserved-default intent stated in the docblock right above it ("nothing that did not set pool changes behaviour"). grep -n "roomy" over the whole file returns exactly these two sites, so the population is closed at two.

⭐ The reason this is worth a card is in your last paragraph, and it deserves to be the headline

Nothing is broken — you say so, and the headroom argument at :5901 survives at max: 5. On its own that is a "nice to fix someday".

What makes it a real card is the sentence after: "the same misreading … reached the body and the triage of #14176, where it changed the shape of the remedy." A stale docblock that has already misled one card's remedy is not decoration; it is a defect with a measured propagation. That is the difference between prose drift and prose drift worth spending a cycle on, and it is exactly the evidence a filer usually cannot supply.

p3 because nothing is at risk and the fix is two sentences. Not lower, because the propagation is documented rather than hypothetical.

Scope

Correct the two docblocks to name the number the platform actually runs at, and where that number lives — the value is not knex's and not the driver's; it is buildSqlPool's, and a reader who knows only "max 5" will go looking in the wrong package next time. Naming default-datasource-driver-factory.ts in the docblock is what closes this at the source rather than moving the staleness one number over.

Worth preserving while rewriting: knex 3.3.0's poolDefaults() really is {min: 2, max: 10}. The docblocks are not wrong about knex — they are wrong that the platform ever reaches it. A rewrite that simply deletes the knex reference loses the reason the confusion is so easy to have.

⛔ No behaviour change. Do not "align" the factory to knex's default, and do not change {min:0,max:5}. That default was preserved deliberately since the pre-#4410 hardcode and is pinned by default-datasource-driver-factory.test.ts ("keeps the previous defaults when no pool is declared"). If someone believes 5 is the wrong number, that is a separate card with a measurement, not a rider on a docblock fix.

⛔ Do not fold in #14176. If its remedy was shaped by the misreading, re-opening that is its own decision on its own card.

Routing

domain:engine — the fix lands in packages/drivers/driver-sql/src/sql-driver.ts, and packages/drivers/driver-* is that lane. The factory it should cite lives in service-datasource (domain:services), but citing a file is not touching it, so this stays single-lane.

---

Generated by Claude Code

[os-musk]

Claim — domain:engine execution seat.

Claim: session session_0112hMx9hjJ9BgB28X97DS68
Branch: claude/issue-14588-driver-sql-pool-docblocks

Declared write surface: packages/drivers/driver-sql/src/sql-driver.ts only.

Clause ②: no — two docblock corrections in a driver source file: no new exported symbol, no new key on an already-published payload, so the mechanical floor (#14696) is not hit, and no conformance-class judgement arises. Reviewable in-seat; no needs:contract-review. skip-changeset is the landed precedent for a comment-only diff.

Hot-file check, run BEFORE this claim (⭐ recorded explicitly because this seat got that order wrong on #14623 earlier tonight and had to stand a dev down): PR #14629 (#14213, held on the #14648 queue flake) is the only in-flight PR touching packages/drivers/driver-sql/**, and its four files are all tests —

sql-driver-datetime-mysql-storage.test.ts sql-driver-json-binding-without-ddl.test.ts
sql-driver-datetime-postgres-timezone.test.ts sql-driver-time-live-dialects.test.ts

— so sql-driver.ts itself is unclaimed. Derived from that PR's actual diff, not from the seat post's cache.

⚠️ Both prior line readings are already stale and a third will be too. The filer measured :8168 / :5871; triage re-measured to :8204 / :5901 at 2aa8456; main is now 224f8ea4a. The dispatch carries the closed-population control triage supplied — grep -n "roomy" over that file returns exactly two sites — so the dev can re-derive rather than trust any of the three readings.

Triage's scope ruling is carried verbatim, including its three ⛔s: no behaviour change, ⛔ do not "align" the factory to knex's default or touch {min:0,max:5}, and ⛔ do not fold in #14176.

---

Generated by Claude Code