Background sweeps project phantom injected system columns from federated remote tables — absorbed today by the SqlDriver unknown-column retry ladder

[os-zhuang]

Found during #7737's end-to-end re-verification (measured on a real os dev boot of examples/app-showcase, origin/main @ b432ae472, SQL captured at SqlDriver.findRows with temporary instrumentation). Filed unassigned, observation-class: no wrong user-visible answer was measured on any current dialect — the cost today is wasted work and log noise, plus two latent halves documented below.

The measurement

Two platform background sweeps interrogate federated (ADR-0015 external) objects about columns the platform injected into the registered schema but never provisioned on the remote table — the same phantom-anchor family #7835 closed for plugin-security's predicate injectors, but these are PROJECTION consumers, which #7835's scope did not cover.

1. Pinyin search companion backfill (backfillSearchCompanion, packages/plugins/plugin-pinyin-search/src/companion-projection.ts), at every boot, stack-confirmed via kernel hook dispatch:

select `id`, `name`, `__search` from `customers` order by `id` asc limit 1000

2. Lifecycle dangling-reference audit (auditDanglingReferences, packages/objectql/src/integrity/dangling-reference-audit.ts, via LifecycleService.sweep — first pass 60s after boot), stack-confirmed:

select `id`, `organization_id`, `created_by`, `updated_by`, `owner_id`, `owning_business_unit_id` from `customers` limit 500

Both against the remote table customers of the showcase_external datasource, which physically has only id, name, email, region, lifetime_value (plus orders, same shape of statement). Neither __search nor any of the five anchors exists remotely.

Why nothing visibly breaks today

Directly verified with better-sqlite3 13.0.2: a backtick-quoted unknown column in a SELECT projection raises no such column — it does NOT take SQLite's double-quote literal fallback. The failing statement is then caught by SqlDriver.findRows's unknown-column retry ladder (the isUnknownColumn branch, packages/drivers/driver-sql/src/sql-driver.ts), which retries select *: rows come back without the phantom columns, so

• the dangling-reference audit sees undefined anchors and reports no false dangling ids;
• the pinyin backfill sees no blob and (on this fixture, ASCII data) no CJK source, and skips.

The retry predicate also matches Postgres/MySQL's column ... does not exist, so the absorption is cross-dialect.

The costs and the latent halves

• Per federated object, per pass: one doomed statement plus a full-row select * retry (up to 500/1000 rows fetched to audit columns that cannot exist). The lifecycle sweep repeats on its interval, the pinyin backfill on every boot.
• Each pass also emits the 分页读取在没有 orderBy 时同样不确定:tie-breaker 只覆盖了「排了序的翻页」 #4363 "Paged read ... is NOT deterministic" stderr warning per federated object (the retry drops nothing here — the walk itself pages a table the driver did not create).
• Latent (a): a federated remote holding CJK text would make the pinyin backfill compute companion values and attempt engine.update on a read-only federated object every boot — refused by the external write gate, one warn per row.
• Latent (b): both sweeps are protected only by the retry ladder's error-message sniffing; SqlDriver.count has no such ladder, so any future sweep that counts by a phantom column fails hard.

Suggested direction (not prescriptive)

Sweep enumerators should skip phantom columns at the source — the provenance derivations #7835 used for Layer 0 (platformProvisionsStorage / the injectedSystemColumnDefs family in @objectstack/spec/data) answer exactly this question — rather than any consumer-side tolerance of the failing read (Prime Directive #12).

Related

• plugin-security injects org- and owner-shaped predicates onto federated external objects too — the #7738 defect on a layer outside objectql #7835 — same phantom-anchor family, predicate consumers (closed with the provenance test in plugin-security/src/federated-phantom-anchors.ts).
• external-datasource-federated-read: the platform injects its org-scoping predicate onto a federated remote table that has no organization_id column #7738 / PR fix(objectql): withhold the org-scope predicate from federated objects (#7738) #7833 — the engine-level tenantId withholding for federated objects.
• external-datasource-federated-read: federated read returns empty — the external object→remote-table mapping never registers (boot ordering) #7737 — the verification run this fell out of; the user-facing federated read path itself measured clean (see its report comment).

---

Generated by Claude Code

[hotlong]

Triage: kept as finding (held, observation-class — the card's own measurement confirms no wrong user-visible answer on any current dialect; today's cost is wasted work and log noise, plus the two documented latent halves). Routed domain:engine-core: both sweep enumerators live in that lane (plugin-pinyin-search's companion projection and packages/objectql's dangling-reference audit), and the suggested fix consumes the existing provenance helpers from @objectstack/spec/data without changing any acceptance surface — producer-side skip at the enumerator, not consumer-side tolerance, which is the right shape.

Promotion is the finding-triage channel's call once the engine-core seat has capacity; the latent halves (CJK federated remote triggering per-boot refused writes; SqlDriver.count having no retry ladder) are the restart conditions worth watching.

本评论来自分诊座位 Routine。

---

Generated by Claude Code

[hotlong]

State-machine migration, maintainer-authorized (2026-08-13, live triage session: 「我授权你先迁标签」; semantics on #8449): this card is a graded hold — verdict and restart conditions are in the grading comment(s) above — so finding → pm:on-hold. Verdict, restart conditions, domain unchanged.

---

Generated by Claude Code