Repository navigation
A SELECT ... WHERE 1 = 0 column-existence probe against _objectstack_sequences is logged at ERROR on a normal boot, before the table exists #17175
Description
Found while upgrading objectstack-ai/hotclm from @objectstack/* 17.3.0 to 17.4.0 (hotclm#35 / hotclm PR #37). Filed at the destination per that repo's AGENTS.md rule for platform gaps — report, never patch. Not triaged: no domain:*, no priority, no assignee.
Symptom
On a clean single-tenant SQLite dev database, every boot after the first logs, at ERROR level:
[sql-driver] DATABASE_ERROR ... SELECT "tenant_id" FROM "_objectstack_sequences" WHERE 1 = 0
- no such table: _objectstack_sequences
WHERE 1 = 0 is the shape of a column-existence probe — a query written to return no rows and answer only "does this column exist". The probe runs against a table that has not been created yet, the driver raises, and the raise is logged at error severity rather than being handled as the negative answer the probe was asking for.
Nothing downstream breaks: the boot completes, capabilities are not degraded, and no application data is touched.
Why it is worth a card even though nothing breaks
Consumers are told to read their boot log. objectstack-ai/hotclm's AGENTS.md says, verbatim:
A boot that logs warnings is not a passing boot. Read the startup banner.
System started with degraded capabilities,no such table, or a plugin that failed to load each mean the app is running as something other than the product.
That rule now fires on a healthy boot. An app author following the documented discipline must either ignore an ERROR line — which trains them to ignore the next one, the one that matters — or chase a platform-internal probe they cannot fix. A probe's negative answer should not be indistinguishable from a real driver failure.
Version boundary
- 17.3.0 — line absent.
- 17.4.0 — line present.
Measured on the same application, same worktree, same clean .objectstack/data, both boots read at seeder quiescence rather than at the ready banner.
Reproduce
git clone https://github.com/objectstack-ai/hotclm && cd hotclm
pnpm install # resolves @objectstack/* 17.4.0
rm -rf .objectstack/data
pnpm demo # boot 1
pnpm demo # boot 2 — the ERROR line appears hereExpected
A column-existence probe against a table that does not exist yet answers "no" without a DATABASE_ERROR at error severity — either by checking table existence first, or by classifying no such table from a WHERE 1 = 0 probe as the negative result rather than a failure.
Related
Sibling finding from the same boot, different root cause, filed separately: the sys_oauth_resource bootstrap re-insert now surfacing as an ERROR.
Activity
os-litant commentedon Sep 10, 2026
Triage: lands in
packages/drivers/driver-sql;domain:engine;priority:p2.A
SELECT ... WHERE 1 = 0column-existence probe against_objectstack_sequencesis logged at ERROR on a normal boot, before the table exists ⇒ every boot after the first prints[sql-driver] DATABASE_ERRO…at ERROR on a clean single-tenant SQLite dev database.⇒ p2: an expected, handled probe reported at ERROR on the happy path. ⭐ The cost is not the line — it is that operators learn this product prints errors when nothing is wrong, and then miss the one that matters. That is the same blindness objectui#8620 describes for test output, on the operator's side.
⇒ Log the expected-miss case at the level it deserves (debug/trace) or probe in a way that does not raise. ⛔ Do not suppress the driver's error channel wholesale — the probe is what should stop shouting, ⛔ not the log.
sys_oauth_resourceUNIQUE refusal at ERROR). ⭐ Together they mean a normal boot prints at least two ERRORs — say so in whichever PR lands second, and check whether a third exists.⭐ Filed at the destination per hotclm's
AGENTS.md— report, never patch.Size/model suggestion:S–M.分诊席位 ·
session_017VGfRocA8VjczSe84fgjY3· R+166 · 2026-09-10T14:56Z · 本评论来自分诊座位Generated by Claude Code
fix(metadata-protocol): one shared non-raising table-presence probe, …
test(metadata-protocol): execute the read-probe PostgreSQL arm on a l…