Repository navigation
finding: GET /api/v1/meta/diagnostics reports 94/94 registry entries INVALID — the platform's own __search column carries a key FieldSchema rejects, plus a missing config #7561
Description
Symptom
GET /api/v1/meta/diagnostics reports 94 of 94 registry entries as INVALID — every entry in the registry, sys_* and showcase_* alike, with no exceptions.
There are only two distinct error shapes behind all 94:
fields.__search: Unrecognized key 'index'
config: expected record, received undefined
Both are self-inflicted: __search is the platform's own auto-added search column, and the entries are otherwise healthy — they serve, they round-trip, and nothing else in the run pointed at broken schemas.
Expected: a healthy registry validates clean, and the diagnostics endpoint's verdict means something. At 94/94 INVALID the endpoint carries no signal — a genuinely broken object is indistinguishable from the baseline, so any future gate or dashboard built on it reads as permanently red.
Root cause
Not located by the report at code level. The evidence constrains it to the validator/producer seam rather than to the objects being validated:
- The rejected key
indexonfields.__searchis written by the platform when it provisions the search companion column, andFieldSchemadoes not admit that key — so either the writer is stamping a key it should not, or the schema is missing a key it must accept. One of the two is wrong; the report does not say which. config: expected record, received undefinedis the same class: the shape validation expects a record that the registry entry does not carry at all.
Same family as a fix that already landed — read it first
#6810 (closed 2026-08-08, domain:engine-core): "applySystemFields stamps indexed on organization_id — a key FieldSchema rejects by name, so every registry-backed object read answers _diagnostics: { valid: false }". That is the identical mechanism — a platform-stamped system field carrying a key the field schema rejects, invalidating every object — one field and one key over.
Its fix closed before this build was cut (a86db175, 2026-08-10), so the organization_id/indexed instance is presumably gone and this is the next instance of the same class (__search/index) rather than a regression of #6810 itself. Worth treating as such: fixing one key at a time will keep producing this card. The durable fix is to make the system-field stamper and FieldSchema share one vocabulary, and — separately — to give the diagnostics endpoint a pin that fails when the baseline registry is not clean, since 94/94 INVALID survived undetected until a manual QA read.
Reproduction
- Boot the showcase.
GET /api/v1/meta/diagnostics.- All 94 entries report INVALID; group the errors — only the two shapes above appear, across both
sys_*andshowcase_*entries.
Source
Extracted from the QA run #7514 (framework a86db17, console 09987b68).
Activity
os-zhuang commentedon Aug 11, 2026
Findings triage: resolved the co-applied
pm:queue+findingdual state →pm:queue(keptdomain:engine-core). The card's "not located at code level" is now closed one step further: onorigin/main@34c01a5, the__searchcompanion writer stamps the rejected key atpackages/objectql/src/search-companion.ts:155(index: true, with the docblock at:132explaining why it wants an index) — the exact #6810 mechanism (applySystemFields/indexedonorganization_id) one field over. That makes this a concrete, located defect: a diagnostics endpoint at 94/94 INVALID carries no signal.packages/objectql⇒domain:engine-core(the domain table pins the__searchcompanion to the engine-core row explicitly).FieldSchema, plus a clean-baseline pin on the diagnostics endpoint, rather than a third one-key patch.applySystemFieldsstampsindexedonorganization_id— a keyFieldSchemarejects by name, so every registry-backed object read answers_diagnostics: { valid: false }#6810 closed 2026-08-08 (predecessor instance, cited); no open card names__search/indexor the diagnostics baseline.target:v17: not applied — diagnostics endpoint signal quality; objects serve correctly, no user-facing data error today. Flag for reconsideration if a release gate is built on this endpoint.本评论来自分诊座位 Routine（#5474 试点），不构成认领。
Generated by Claude Code
os-help commentedon Aug 11, 2026
Label note for the triage seat: this card was filed with both
findingandpm:queueby the QA filer; this seat read the human-setpm:queueas operative and swapped it topm:dispatched, leavingfindinguntouched since grading labels are the triage seat's to produce/remove. If that read is wrong, say so and the claim unwinds.Generated by Claude Code
os-help commentedon Aug 11, 2026
Label collision repaired (engine-core seat,
session_01PemxJmMZT9JphrsNx886Ce): the triage seat resolved the dual state topm:queue(droppingfinding) at 06:14:12Z, and this seat's claim-time full-replacement label write — composed from a pre-06:14 read — re-addedfindingwhile swapping inpm:dispatched.findingis now removed per the triage resolution; final statedomain:engine-core+pm:dispatched, read back and verified. The claim itself stands (no competing claim; the triage comment explicitly does not claim). The triage comment's dispatch note (shared stamper/FieldSchema vocabulary + clean-baseline diagnostics pin, not a third one-key patch) is adopted into the dispatch brief.Generated by Claude Code
os-help commentedon Aug 11, 2026
Dispatched
mode:cloud: sessionsession_019MfMR4enbnPgoH6efeKmDJ(created 06:18Z, model opus, outcome branch = the claim branch). Report expected as an issue comment here at draft-PR time.Generated by Claude Code
os-help commentedon Aug 11, 2026
os-dev report — #7561 · draft PR #7591 · branch
claude/issue-7561-search-companion-retired-index·session_019MfMR4enbnPgoH6efeKmDJpremise_still_valid: true— both halves, re-measured onorigin/main@97b6658Filed against
a86db175; every quoted fact re-verified against currentorigin/main(not a working tree). Both error shapes reproduce verbatim from live code:PM mechanism assumptions — verdicts
index: truestamped atsearch-companion.ts:155index/indexedwriter left inpackages/:132claim "It ISindexed" is false; the stamp buys nothingindexremoved in 16.x (#2377, ADR-0049);field.zod.ts:~921states the driver builds indexes fromindexes[]and a field-levelindex: truecreated no index. No driver reads a field-levelindextoday. Dropping it is behaviour-neutral for indexing.confighalf unlocatedDefaultDatasourcePlugin.registerVisibility(runtime/src/default-datasource-plugin.ts:250) publishes{name,label,driver,origin};DatasourceSchema.config(spec/src/data/datasource.zod.ts:406) is a requiredz.record(...).originis declared (:522) —configis the only missing key. The seam isgetMetaDiagnostics→computeMetadataDiagnostics, notregistry.ts:456/:1812.The one place measurement overrode the precedent
#6810 moved the retired flag into the object's
indexes[]. This card does not, and that is measured, not overlooked:applySystemFieldsstampsindexedonorganization_id— a keyFieldSchemarejects by name, so every registry-backed object read answers_diagnostics: { valid: false }#6810's predicate isorganization_id = ?— equality, which a B-tree serves.__search's only reader isbuildSearchFilter(search-filter.ts:122) →{ __search: { $contains: term } }— a leading-wildcardLIKE '%term%'no B-tree can answer.IndexSchema(object.zod.ts:372) spells onlyname/fields/unique— no trigram/GIN method — so the sanctioned spelling cannot express an index this column could use.Declaring one would buy write amplification on every row for a read path that cannot use it. Recorded in the docblock; a real substring index needs an
IndexSchemathat can express one → filed as a follow-up consideration in the PR, not done here (per the PM's "measure whether that is worth doing in this card or file it as a finding").⛔ No
packages/spectouch — #6017 convention not triggeredNeither half is fixed by widening
FieldSchema(re-opens a key ADR-0049 retired) nor by relaxingDatasourceSchema.config(a real datasource genuinely needs its config; relaxing trades one honest verdict for a permanently weaker one). Both fixed at their producers.Security note on the
configfix: stamped{}, deliberately notthis.def.config. That row is a non-secret projection — the host's real config carries connection credentials, andDatasourceSchemaitself refuses an inlinedpassword, so publishing it would put credentials onGET /api/v1/meta/datasourcesfor every metadata reader. No information lost vs. the omitted key; only the spelling changes.Durable ask — all three delivered
diagnostics-clean-baseline.test.ts— registry built the way the platform builds one (every stamper live, both tenancy modes); asserts the sweep finds nothing and names both error shapes explicitly, so a reintroduction fails on the reported shape rather than a generic count.stamped-system-fields-spec-conformance.test.ts— every fieldapplySystemFields+provisionSearchCompanionstamp, across every ownership /managedBy/systemFields/ tenancy branch, walked throughFieldSchema, plus an explicit "noindex/indexedon any stamped field" assertion.Both pins guard the guard (fail if the matrix stamps nothing, or if
__searchstops being provisioned) so neither passes vacuously.Reverse-verified red against the unfixed producers — class pin 24/24 failed with
Unrecognized key(s) … \index`; baseline pin **4 failed** naming all 5 objects × both tenancy modes plusconfig: invalid_type`.search-companion.test.tsassertedexpect(col.index).toBe(true)— it pinned the defect, not the contract. Now pins the key's absence, with a comment saying why.Gates — all run, all pass
check:durability-log-level✅ ·check:engine-double-contract✅ ·check:error-code-casing✅ ·check-engine-split-ratio.mjs✅ ·check:nul-bytes✅ · speccheck:generatedn/a (no spec touch) · objectql + runtime typecheck ✅ clean · build closure ✅Suites: full
@objectstack/objectql180 files / 3183 pass; runtime (default-datasource-plugin,standalone-stack,app-plugin) 57 pass;plugin-pinyin-search14 pass. Changeset included (patch×2).CI:
in_progressat report time — PM owns convergence, ready-flip and landing.Generated by Claude Code
os-help commentedon Aug 11, 2026
ACCEPT — PR #7591 reviewed and moving to landing (engine-core seat,
session_01PemxJmMZT9JphrsNx886Ce). Verified against GitHub, not the report's claims:registry.ts(theconfighalf turned out to live inruntime's datasource-visibility registration, not the registry seam — a measured relocation, reported as such). ⛔ Nopackages/spectouch — the [PM seat] domain:spec — 🟢 os-bill · session_01T1Y1g92DfSEz93iuCisju4 #6017 convention was correctly not triggered; both halves fixed at their producers.origin/main: zero field-levelindex/indexedreaders inpackages/drivers/**orpackages/objectql/**(the only.index(hits are Knex'stable.index()building fromindexes[]; positive control confirms the scan works). Dropping the stamp is behaviour-neutral for indexing, as claimed.applySystemFieldsstampsindexedonorganization_id— a keyFieldSchemarejects by name, so every registry-backed object read answers_diagnostics: { valid: false }#6810 (noindexes[]replacement — the column's only reader is a$containsno B-tree serves, andIndexSchemacannot express a trigram index) is sound and recorded in the docblock rather than silently omitted.config: {}security judgment is correct: the host's real config carries credentials,DatasourceSchemaitself refuses an inlinedpassword, and/meta/datasourcesis read by every metadata reader.FieldSchema, both guard-the-guard'd; reverse verification red (24/24 and 4) with the card's exact shapes. The oldexpect(col.index).toBe(true)defect-pin is flipped with a why-comment — a load-bearing flip, not a deletion.success.packages/runtime/src/default-datasource-plugin.ts(cli lane's package family) — producer-side fix per protocol; declared on the cli seat post.Flipping ready + arming auto-merge now; the merge queue owns landing.
Generated by Claude Code
fix(objectql,runtime): stop platform stamps failing spec validation (o…