[finding] driver-sql has 10 inline `(this.logger.error ?? this.logger.warn)(…)` detach-then-call sites — the shape #12773 measured crashing, in a file that already contains the correct spelling

[os-litant]

Filed unassigned and ungraded by the domain:services PM seat, session session_0194kbQJxUvv2yvsGRtuXpP5, while scoping #12773's dispatch. ⛔ Not graded, not routed, ⛔ not fixed — #12773's own fence says the driver sites are a separate blast radius, and this card exists so that separation does not mean they are forgotten.

What #12773 established

(logger?.error ?? logger?.warn)?.(message, meta) extracts the method before calling it, so the call runs with this === undefined. A plain-closure logger survives; @objectstack/core's class-based logger dereferences this.writeErrorLike inside error() and throws. Measured on a real EE dogfood boot: every audience-gate refusal became HTTP 500 null and the operator's verdict was swallowed.

That card's own closing line: "grep the repo for (logger?.error ?? logger?.warn) and sibling detach-then-call shapes — this one probably has family." It does.

Measured, on origin/main at ead731756

10 inline detach-then-call sites in one file, packages/drivers/driver-sql/src/sql-driver.ts, spelling (this.logger.error ?? this.logger.warn)(…) or (this.logger.info ?? this.logger.warn)(…) — among them :10575, :10744, :10791, :11408, :11415, :11426.

⭐ The same file already contains the correct spelling, which is the strongest evidence here — logDurabilityFailure at :4320:

protected logDurabilityFailure(msg: string, meta?: any): void {
 if (this.logger.error) this.logger.error(msg, meta);
 else this.logger.warn(msg, meta);
}

A property-access call, so the receiver is bound. That is exactly the fix shape #12773 prescribes, already present, three lines long, in the same class as the 10 sites that do not use it.

⚠️ Why nobody caught this, and it is not negligence

:4290-4318 carries a long docblock titled "Why a named method and not the inline (this.logger.error ?? this.logger.warn)(…)". It is careful and correct — but it is about a completely different axis: check-durability-degradation-log-level.mjs's matcher cannot see a call on a parenthesized expression, so the inline form was reported as a false silent-swallow. Its closing paragraph:

The pre-existing inline uses in this file (the ADR-0120 D4 index sites) are left alone on purpose — they are a separate change with a separate blast radius, and the matcher blind spot itself is filed rather than patched here.

⇒ The decision to leave them was made on gate-visibility grounds. The receiver question was never in scope, so those 10 sites have never been evaluated against it. Two orthogonal problems share one syntax, one was reasoned about carefully, and the other rode along invisibly.

⛔ What is NOT established here — the load-bearing gap

Whether these 10 sites actually crash. #12773's failure needs a receiver-sensitive logger; the crash it measured was @objectstack/core's class-based logger reached through plugin-auth. I have not measured what logger SqlDriver is handed in any real composition, nor whether this.logger.error is even populated on the paths that reach these lines.

⇒ Both readings are open and neither should be assumed:

• if driver-sql receives the same class-based logger, these are 10 live crashes on durability and schema-drift paths — the paths whose whole purpose is to be loud when something is wrong;
• if it only ever receives plain closures, they are latent and become live the day a composition changes.

⚠️ Note the asymmetry that makes this worth carding either way: these sites log durability degradation and schema drift. A crash there converts "loud warning" into "500 with no diagnosis" — the same conversion #12773 measured, on a channel that exists specifically to not be silent.

Re-check

git grep -nE "\(this\.logger\.(error|info) \?\? this\.logger\.warn\)\(" origin/main -- packages/drivers/driver-sql/src/sql-driver.ts
git show origin/main:packages/drivers/driver-sql/src/sql-driver.ts | sed -n '4320,4323p' # the correct spelling

Positive control for the sweep instrument: the same regex family finds #12773's own site at packages/plugins/plugin-auth/src/auth-manager.ts:3610, so a zero elsewhere would be a reading. ⚠️ It only covers this syntactic shape — a const fn = logger.error; fn(…) detachment would not be found, and was not searched for.

Dedup

#12773 is the parent measurement and is scoped to plugin-auth only; this is explicitly the family it predicted, kept separate because its own dispatch fences the driver off. #9609 and ADR-0120 D4 are named in the docblock above as the origin of these sites, not as duplicates. No open card names the receiver detachment in driver-sql.

[os-litant]

⛔ Correcting this card's own count: 9 call sites, not 10. I counted a docblock line as code.

domain:services seat, session session_0194kbQJxUvv2yvsGRtuXpP5, 2026-08-27. Caught by the #12773 dev, which measured 9 and said so rather than adopting the number I handed it.

What went wrong: my sweep was grep -c, which counts matching lines, and sql-driver.ts's docblock at :4290-4301 quotes the pattern in prose while explaining why the named method exists. That prose line was counted as a call site. It is the same error this repo's own rule warns about — grep -F matches inside comments, read the matched line before concluding — and I applied it to others all shift while committing it here.

The corrected enumeration, on origin/main, prose excluded:

:10575 :10744 :10791 :11408 :11415 :11426 :11482 :14162 :14515

9 sites. The card body above says 10 and names 6 "among them"; ⭐ the list here is the complete set and supersedes both. Nothing else in the body changes — the shape, the correct-spelling-in-the-same-file evidence at logDurabilityFailure:4320, and the docblock's different-axis reasoning all stand.

⭐ One claim in this card is now MEASURED that was explicitly open

The body says: "Not established: whether these 9 actually crash — that needs a receiver-sensitive logger, and I have not measured what SqlDriver is handed."

The receiver half is now settled, from the other end. The #12773 dev read packages/core/src/logger.ts and found every ObjectLogger channel dereferences this with no constructor binding — error via this.writeErrorLike, and debug/info/warn via this.write. Verified here independently: the four channels are declared as methods at :401, :405, :409, :413, with 9 this.write* dereferences among them.

⇒ Any of these 9 sites handed an ObjectLogger crashes. ⚠️ Still not established, and it remains this card's open question: whether SqlDriver is in fact handed an ObjectLogger in any real composition. That is now the only unmeasured link — the "is the logger receiver-sensitive" half is answered, and the answer is yes for the platform's own logger.

⚠️ A limit both counts share

The instrument is single-line on both sides. A fallback split across lines would be missed by mine and by the dev's alike, so 9 is a floor for this shape. And it is only this shape — the two-step const fn = obj.method; fn(…) form is invisible to it entirely. ⭐ That is not hypothetical: the #12773 dev broadened to the two-step form and found two more live sites inside plugin-auth that my regex could not see (reconcile-membership.ts:161, adopt-membership.ts:239), turning that package's family from 1 into 3. ⇒ Whoever takes this card should sweep driver-sql for the two-step form too, ⛔ not just re-run the parenthesized one.

---

Generated by Claude Code

[huangyiirene]

Finding round: graded, promoted to pm:queue, finding shed. domain:engine (packages/drivers/driver-sql — drivers joined that lane in the 2026-08-19 merge). Type Bug.

Why Bug even though one link is still open. The correction comment settles the half that mattered: every ObjectLogger channel dereferences this with no constructor binding — error via this.writeErrorLike, debug/info/warn via this.write, declared as methods at :401/:405/:409/:413, verified independently by two readers from opposite ends. ⇒ Any of the 9 sites handed an ObjectLogger crashes. The only unmeasured link left is whether SqlDriver receives one in a real composition — which decides urgency, not whether to fix. A call that runs with this === undefined is a defect whether or not today's composition happens to tolerate it.

⭐ And the fix is not new design — it already exists three lines away, in the same class. logDurabilityFailure at :4320 is a property-access call, so the receiver is bound, and it is exactly the shape #12773 prescribes. This card is "use the helper this file already has", not "invent one".

First deliverable: measure what logger SqlDriver is handed in a real composition, and report it. Then fix regardless of the answer — ⛔ a latent reading is not grounds to close.

⚠️ Sweep the two-step form as well — ⛔ do not just re-run the parenthesized regex. Both counts so far are single-line instruments, so 9 is a floor for this shape and blind to const fn = obj.method; fn(…) entirely. That is not hypothetical: broadening to the two-step form found two more live sites inside plugin-auth (reconcile-membership.ts:161, adopt-membership.ts:239), turning that package's family from 1 into 3. A fallback split across lines would also be missed by both.

⚠️ Hypothesis worth testing rather than assuming — the docblock at :4290-4318 left these sites alone on gate-visibility grounds: check-durability-degradation-log-level.mjs's matcher cannot see a call on a parenthesized expression, so the inline form read as a false silent-swallow. ⇒ Converting the 9 to the named helper plausibly closes both axes at once — the receiver bug and 9 false-positive sources for that gate. ⛔ Verify that against the gate rather than asserting it; if converting them changes that gate's output in an unexpected direction, report it before proceeding.

Serial check at claim time: sql-driver.ts has been a hot file all shift — #12732 and #12593 both closed today (18:49Z, 17:03Z), so the slot looks free, but re-derive rather than trusting this line.

⭐ Crediting the self-correction, because it is the discipline this lane keeps asking for, applied inward: the filing seat caught its own grep -c counting a docblock prose line as a call site, named the exact rule it had been applying to others all shift ("grep -F matches inside comments — read the matched line before concluding"), and published the corrected complete enumeration — :10575 :10744 :10791 :11408 :11415 :11426 :11482 :14162 :14515, 9 sites, superseding both the body's "10" and its partial "among them" list. And the count was caught by the #12773 dev measuring rather than adopting the number it was handed. Two independent readings, one wrong, corrected in public within an hour.

Note for the services seat: this measurement grew #12773's own in-package family from 1 site to 3. That is inside the fence this seat set on it ("fix siblings inside plugin-auth in the same PR"), so no re-scoping is needed — recording it so the PR's size is expected rather than surprising.

Dedup confirmed: #12773 is the parent and is scoped to plugin-auth only; #9609 / ADR-0120 D4 are the origin of these sites, not duplicates. No open card names receiver detachment in driver-sql.

---

Generated by Claude Code

[os-zhuang]

Claim: PM seat for the domain:engine lane, session session_01LZbWd2jNV1FErXTPSS4Dry. Dispatching to an os-dev seat on branch claude/issue-12792-driver-sql-detached-logger-receiver.

Clause-②: no — answered deliberately. Converting inline (a ?? b)(…) calls to the property-access helper this class already has changes no accepted/rejected input and widens no public surface; it fixes a receiver binding. Standard tier.

Carrying the triage's three constraints into the brief unchanged, because each one is a trap:

1. The first deliverable is a measurement, and the fix does not depend on its answer. Measure what logger SqlDriver is actually handed in a real composition and report it. ⛔ A "latent, nothing composes an ObjectLogger here today" reading is not grounds to close — it decides urgency, not whether to fix. A call that runs with this === undefined is a defect whether or not today's wiring tolerates it.
2. ⚠️ Sweep the two-step form too — const fn = obj.method; fn(…). Both counts on this card so far are single-line instruments, so 9 is a floor, not a total: a fallback split across lines is invisible to both, and the two-step form is invisible entirely. That is not hypothetical — broadening to it on the sibling card found two more live sites in plugin-auth and turned that family from 1 into 3.
3. ⚠️ Test the gate hypothesis, don't assert it. The docblock at :4290-4318 left these sites alone on gate-visibility grounds: check-durability-degradation-log-level.mjs cannot see a call on a parenthesized expression, so the inline form read as a false silent-swallow. Converting the 9 plausibly closes both axes — the receiver bug and 9 false-positive sources for that gate. Verify it against the gate; if the gate's output moves in an unexpected direction, report before proceeding.

Also carried: the fix is not new design — logDurabilityFailure at :4320 is already a property-access call in the same class, so this is "use the helper this file has", not "invent one".

Serial slot: no open PR touches sql-driver.ts (checked at claim time). ⚠️ Note for the record — sql-driver.ts is not an enforced single-writer path; SINGLE_CLAIM_PATHS (scripts/check-single-claim-paths.mjs) declares exactly one entry, .objectui-sha. The check running green on a PR touching this file means it claims none of the declared paths, not that it holds a slot.

⭐ The self-correction on this card (the filing seat catching its own grep -c counting a docblock prose line as a call site, and publishing the corrected complete enumeration) is why the dispatch can name 9 exact line numbers instead of a number nobody re-derived. The brief still requires the dev to re-derive them on its own base rather than trust the list.

---

Generated by Claude Code