SchemaRegistry.resolveObjectKey scans the whole registry per lookup, making kernel boot quadratic in stored metadata

[os-zhuang]

SchemaRegistry.resolveObjectKey rescans the ENTIRE object registry on every name lookup, so kernel boot is quadratic in how much metadata an environment has stored.

// packages/objectql/src/registry.ts:2366
private resolveObjectKey(name: string): string | undefined {
    const matches: string[] = [];
    for (const fqn of this.objectContributors.keys()) {   // ← every registered object
      const { shortName } = parseFQN(fqn);                 // ← per entry, per lookup
      if (shortName === name) matches.push(fqn);
    }
    …
}

It is called from at least seven sites in the same file (1842, 2346, 2453, 2476, 2703, 3133, 3365) — getObject(name) among them — so a boot that registers N objects and looks up O(N) names does O(N²) string work with parseFQN as the inner loop.

Measured

Instrumenting a real per-environment kernel build (ArtifactKernelFactory.create(), full hosted capability slate, real TursoDriver in remote transport over a local libsql file) and sweeping the number of env-wide sys_metadata rows the kernel hydrates at boot (ObjectQLPlugin({ hydrateMetadataFromDb: true }), which the cloud tenant runtime always sets):

sys_metadata rows   bootstrap step   marginal ms/row   database round trips
              0            63 ms            —                  242
            500           232 ms         0.338                 243
          1,000           422 ms         0.380                 243
          2,000         1,036 ms         0.614                 243
          4,000         2,627 ms         0.798                 243
          8,000         8,533 ms         1.496                 315

Round trips are FLAT — this is not I/O. Log-log fit of (bootstrap − baseline) against row count: exponent 1.413, R² = 0.994.

A --cpu-prof of the 8,000-row boot names the loop directly. Self time attributed to parseFQN + resolveObjectKey + getPackagedObjectOwner:

sys_metadata rows    registry-scan self time
          1,000                80 ms
          2,000               192 ms   (2.4x)
          4,000               631 ms   (3.3x)
          8,000             2,325 ms   (3.7x)

Each doubling multiplies the cost by ~3.7 — exponent ≈ 1.89, i.e. quadratic. parseFQN is the single largest non-database entry in the profile.

Why it matters

This is the mechanism behind objectstack-ai/cloud#1555: a hosted environment whose bootstrap step takes 134 s against a 20 s request waiter, so every request answers kernel_warming and the environment can never be opened. The build never fails — it is just slower than anything will wait for. Boot cost that is quadratic in stored metadata means an environment gets permanently unservable purely by being used, with no error anywhere.

Direction

objectContributors is keyed by FQN; the short-name→FQN direction wants its own index maintained alongside it (a Map<shortName, fqn[]> updated in register/unregister), turning every one of these lookups into O(1). The ambiguity warning the current loop emits is preserved by keeping the array of matches per short name.

Two properties worth pinning with the fix: a lookup must not depend on registration order, and unregisterObject must keep both maps in step — the extraction note at registry.ts:2350 says the read and the name-addressed removal must not disagree about which contributor a bare name addresses, and a second index is exactly where that could drift.

Reproducing

objectstack-ai/cloud: node scripts/dev-local/bootstrap-curve.mjs --hosted --meta-rows 0,1000,4000,8000

Refs objectstack-ai/cloud#1555

[huangyiirene]

Triage first-touch (bare-card sweep): queued pm:queue, Bug + priority:p0, domain:engine (lands in packages/objectql/src/registry.ts).

p0 rationale: this is the measured mechanism behind cloud#1555 — a hosted environment whose bootstrap outgrows the 20s request waiter becomes permanently unservable with no error anywhere, purely by accumulating metadata; production is at 134s today. Quadratic curve pinned to R²=0.994 with a CPU profile naming the loop. Queue-jump is priority, not exemption — claim protocol and the registry file's in-flight neighbours still apply.

Fix per the card's direction: a short-name→FQN index Map maintained beside objectContributors in register/unregister, preserving the ambiguity warning via per-name match arrays. The two properties the card names are the required pins: lookup independent of registration order, and unregisterObject keeping both maps in step (the registry.ts:2350 extraction note is the contract — a second index is exactly where read/removal could disagree). Acceptance: the seven call sites go O(1); a scaling test (or the cloud rig re-run, stated which) shows the bootstrap curve flatten.

---

Generated by Claude Code

[os-zhuang]

Maintainer ruling (2026-08-22, verbatim): 「#10945 判了 p0:注册表短名查找全表扫描 ⇒ boot 随存量元数据二次方增长,就是 cloud#1555『134s bootstrap vs 20s waiter、环境永久打不开』的机制卡。修法一张索引 Map,engine 席下一轮就能派。」

Mechanism link for the record: cloud#1555's incident math — every registered object triggers short-name resolutions that each scan the whole registry, so boot cost ~O(n²) in stored metadata items; jack's environment crossed the 20s kernel waiter at ~134s bootstrap and 503'd until placement+seed fixes masked the constant factor. This card removes the QUADRATIC factor itself (one keyed index Map alongside the registry), which also shrinks every environment's cold-boot as metadata accumulates — the placement work (cloud#1521) only fixed the per-leg constant. Queued for the engine seat's next round per the ruling.

[os-zhuang]

Claim: PM loop round 1
Session: session_01RfyXxZ2WPjcjhuXpiQQc3y
Branch: claude/issue-10945-registry-shortname-index
Worktree: objectstack-issue-10945
Domain: domain:engine
File surface: packages/objectql/src/registry.ts (region: resolveObjectKey + the register/unregister sites that must maintain the second index) (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus (tier per node scripts/pm/dispatch-gates.mjs --tier packages/objectql/src/registry.ts — no path-derived mandate, floor sonnet/default opus; raised to opus, not left at floor, because the ordering/unregister invariants are a judgment face, not a gate-decided one)
Clause-②: no — an internal short-name→FQN index behind a private method; the accept set is unchanged and no public surface widens. Flagged for the dev: if the repair turns out to require changing what getObject(name) resolves to for an ambiguous short name in a way callers can observe, stop and report rather than deciding it.
Serial constraints cleared: packages/objectql/src/registry.ts has no in-flight claim and no open PR — lane has zero pm:dispatched cards at claim time. Last touch on the file is 9b0172d (unrelated). Sibling cards in this batch (#11020 packages/formula, #10997 driver-sql, #11015 metadata-protocol/runtime) are package-disjoint from this surface; none of them pins registry resolution behaviour.

Premise re-verified live on origin/main @ 4257e4e before dispatch: resolveObjectKey at registry.ts:2366 still scans this.objectContributors.keys() with parseFQN per entry, and all seven call sites named in the card are present (1842, 2346, 2453, 2476, 2703, 3133, 3365).

---

Generated by Claude Code